[ Silence ]
>> All right.
So welcome back to Computer Science S-76.
This is the last time we'll meet in this more formal setting.
Recall that next Wednesday is our app party at which point all
of your projects will be more
than several days done most likely and we'll gather
in the lab room and we'll have some cake and some snacks
and some chitchat, and the goal will be to bring your app,
to bring your laptop as appropriate
and actually demonstrate what you did not only
for your last project, but maybe your first project or two
as well, particularly if you took novel approach
to the user interface or generally just want to show off.
So tonight, we wrap up our look at iOS,
but first, a couple of things.
You know that we've had a team of folks behind the scenes here
and in front of the camera, namely Chris, and RJ, and Rob.
So I just wanted to publicly thank them for all
of their efforts thus far.
Thank you.
[ Applause ]
And also to folks you haven't probably met in person,
but Shelley and Ramone and Dan who've been running things
behind the scenes.
So thank you to them as well.
[ Applause ]
Just in case you would like to relive this summer experience
and realize that the videos will remain online at CS76.tv
for the next few years most likely, for better or for worse.
So, if after the class ends and you're back in school or back
at work, you'd like to at least review material or pull up PDFs,
or sample code of the like, I know that that will continue
to survive on the internet.
So feel free to tune in there.
So a couple of outstanding details here.
So we started the semester looking and talking
about web apps versus native apps.
Someone want to recap in just a sentence
or two what the distinction is and was?
[ Pause ]
Five weeks later?
What's a difference?
>> So the web apps are much more portable,
you can them across browsers.
>> OK. Good.
So web apps are much more portable,
you can use them across browsers.
>> You can get access and also use special tools [inaudible]
numbers and--
>> OK. Good.
But certain special hardware is typically inaccessible to you.
Things like the accelerometer for which browsers like Safari
and the like don't necessarily provide an API 2.
Good. Other thoughts?
>> Native apps run natively on the iOS whereas web apps have
to be downloaded via HTTP [inaudible]--
>> OK. So web apps do have to be downloaded via HTTP
in the context of the browser before they can actually be run,
but you kind of give us a circular definition before.
What does it mean for native apps to be native?
>> Native apps are a [inaudible] the iOS and so you do not have
to retrieve with it some others source.
>> OK. Good.
So you don't have to retrieve them from other source other
than the first time installation from the App Store
which is another compelling feature perhaps,
most people know how to find apps in the App Store,
but most people probably you don't know how
to actually bookmark a web page so that it appears
to be an application which was a technique we looked
at way back early on.
So if you had to choose right now for your third
and final project which you do,
how many folks are leaning toward or already
down the road of web apps?
OK. So, handful six or so-- and the native apps?
OK. And most everyone else.
So not better at all.
So we have a good mix of at least both at that class.
So, all right, so that was web apps versus native apps.
What if you didn't necessarily have to choose
between two [inaudible] contrast?
Well, it turns out that there are wrappers
and the most popular of which is probably something called
PhoneGap which allows you to write web apps
that create the illusion of them actually being native apps.
And by this, I mean, you go to PhoneGaps website
and you download what kinds--
what essentially is a starter code that they have written
for Objective-C, for Java, for Windows Phone, for a whole bunch
of other platforms as well and they've implemented
in different ways and each of those languages hooks
into the native hardware.
And then I have exposed that via JavaScript to WebCode.
So in short, you couldn't theory implement an application
entirely in HTML5, CSS, and JavaScript,
but you can actually ship it to the Apple App Store
and the user could download it and it would have an icon,
and they would have gotten it for free or 99 cents,
whatever the case may be.
And when they run it, it's actually native iOS code running
on the phone, but the contents
of the rectangular window are largely coming
from some website externally.
In fact, this is how the earliest version
of the Facebook application was written.
Some of you might recall that it used to be much slower,
which is actually a downside of taking that approach.
You don't necessarily get the same lack of latency
that you might in an iOS native application, but the upside is,
one, you don't have to learn Objective-C and iOS.
Two, you have access to tools and more familiar environments
which for most people is web-based these days.
And three, I'm kind of out of reason, so two.
So we have two pretty compelling reasons.
So how do you go about doing this?
Well, technologically, this is actually implemented
in kind of a clever way.
So first and foremost,
this technique using PhoneGap actually gives you access
to quite a bit of hardware and contrast
to what we proposed was the case a few weeks back.
So, all of the green boxes here represent a native hardware
that is supported on Android, BlackBerry, iOS, Windows Phone,
and so forth, things like the accelerometer, the camera,
the compass, and other details
that are typically inaccessible to JavaScript.
But by downloading this starter code which is native,
you're therefore providing a bridge of sorts
between native code and JavaScript code.
And the means by which they did this in the iOS platform,
though it differs on others,
is the PhoneGap folks essentially register
with their iOS native application URLs
of the form gap, colon, slash, slash, and then something
and they essentially have an MBC style approach here
where you can then specify as part of this URL a class name,
and a command, or a method to actually call,
and then some number of arguments.
So in another words, they kind of made up their own sort
of protocol by teaching iOS to handle URLs that appear inside
of a browser window via code that they've written.
So it turns out there's a protocol called
the UIWebViewDelegate.
And if you implement this, you can actually be the code
that is invoked when an otherwise foreign URL is used
in the confines of an embedded web browser.
And indeed, that's how PhoneGap works.
You write WebCode that you therefore embed inside
of a rectangular window that's just an embedded web browser
and if you want to talk to the native hardware,
you essentially do this by way of the URL bar.
So this delegate class allows you
to specify what codes should get invoked
when the embedded browser window sees a URL that start
with gap, colon, slash, slash.
And meanwhile, there's also a UIWebView.
This is the class.
So even if you've not used it before, it allows an iOS code
to embed a browser inside of your own native app and it turns
out there's a method associated with this class called string
by evaluating JavaScript from string which means
that your code can be injected into the local browser
and then executed by way of this method.
So in short, this provides a bridge of sorts
between native iOS code and the browser by way
of this URL-based trick.
And there's one other step to this whereby--
or rather in other operating systems,
this is done a little bit differently.
But I'm sure Apple provided enough in the way of hooking
that folks like PhoneGap are able to come along and allow you
to implement your next app
as really a web app underneath the hood,
composed almost entirely of JavaScript with a bit
of Objective-C that some other folks have written.
So I would consider that perhaps
for your next project well beyond courses
if that's of interest.
Questions?
All right.
Well, what about provisioning?
Sadly, some of you have struggled
with this this past week because you may know a hacker
or some prosecuted white-hat type person found some
vulnerabilities in Apple's developer portal.
The result of which is that he was able
to compromise supposedly a whole bunch of names
and e-mail addresses of all of us
who have [inaudible] registered for the iOS developer portal.
And to my knowledge, this was the first time
that Apple proceeded to take the entire thing offline for,
I think, over a week which is wonderfully [inaudible] time
for someone likes us.
So, apologies to those of you who have struggled with this,
but this means now that that thing is starting
to comeback online, you can, in fact, provision your device
to run software written by you.
So if you have an iOS device, iPhone, iPad, or iPod,
you can eventually, if not already, go to URL like this,
follow the online documentation, and frankly,
this is one of the biggest headaches of iOS development.
Just getting your damn code onto your own phone, it's not nearly
as simple as it is in the Android world
or in other platforms because you essentially have
to upload a public/private key pair or portion thereof
to Apple, so as to register some cryptographic key
with them then your code has to be digitally signed
in such a way that it's allowed to run on your own phone even
if you're doing all these at home with a USB cable
and this costs you only 99 dollars a year
for this privilege.
So, long story short, this is a huge headache,
and every time I go, it changes every year but you can kind
of muscle through it with the documentation
which has gotten better overtime, but the end result is
that you can run the software on your own phone.
If you want to distribute it to friends,
you'll have to go buy a way of the App Store or there are ways
over the air that you can distribute apps
for testing's sake, and there's also for those of you
who work professionally, there's an enterprise level account
for 299 dollars a year, or 199 that allows you to share code
that you've written other folks on the development team,
which makes it a little easier to at least share
and test software among each other.
So, not a particularly fun process,
but there is quite a sense of gratification, I think,
once you've got in your own code working on your own phone.
So, aspire to that perhaps for next week
and realize you don't have to pay any of those fees.
Assuming the member center as it's called as back up
and running, we can provision your phone for you.
You can fill up the form that's linked on the course's website,
and in the specification,
so that you can then use our academic account at least
for the remaining couple of weeks of summer school.
All right, so we're fortunate today to be joined by folks
who will bring us two different perspectives
on how Mobile Software Development can be done.
First is Dan Armendariz who's a buddy of mine
and also the former instructor of this course back
in a day we doubled in both iOS as well as Android development.
And Dan has come back from California to join us
for an hour's chat this evening
about how Android development compares and contrasts
with Native iOS developments.
We're also fortunate to be joined by a friend of ours
from down the street at Microsoft NERD,
New English Research & Development.
Bob Familiar is joining us tonight to take a look
at Windows Phone development and also some
of the latest features in Windows 8.
So those of you who've been following some
of the progression of that operating system,
even has a neat beta and demo for us take a look at.
So without further ado, allow me to introduce Bob Familiar
who will join us for the next hour.
Bob.
>> Thanks a lot, David.
>> Thanks so much.
[ Applause ]
[ Pause ]
>> So, good evening.
First, I thank you for the opportunity
to be here and to talk to you.
As David said, my name is Bob Familiar.
I'm the director of technical evangelism
for Microsoft here in northeast.
Myself and my team, we work with students
and professional developers.
We teach them how to build apps for Windows Phone,
for Windows 8, leveraging our Cloud, Windows Azure, and,
you know, we do that through activities that we do online,
through our blogs, through engaging in technical forums.
But we also run a lot of hands-on workshops
on college campuses and other offices across the country.
So what I want to talk to you
about tonight is modern app development on Windows.
So the agenda is, I just want to talk about, you know,
what does it mean to develop for Windows.
I'm going to dig in a bit.
We'll look at some code.
We'll talk about building apps that you use open data APIs.
So if you've been interested in building apps for iOS
or for Android or for Windows, and you're interested, hey,
you know, I'd like to do something
with that Instagram API, or it's Yelp, or Facebook, Twitter,
I'm kind of go over that design pattern.
I'm going to show you some examples, we'll dig into it.
I, myself, am a C# developer
so I'll be using the C# programming language
to demonstrate that.
But the great news is that the pattern I'm showing you is
applicable, you know, really very much
in a cross-platform way and you just, you know,
there's different ways
to implement it whether you're doing JavaScript
or you're developing in Java for Android
or on the Apple platform.
So it just changes in languages syntax at that point.
Now, I'll close out and just really ducktail nicely what
David is talking about with PhoneGap.
I'm going to cover just the cross-platform app
and game development landscape.
As you go into this space, if this is your, you know,
this is your career aspiration,
one of the things you really want
to understand is what are all the different ways
that you can build apps and games or these platforms.
And if you're doing it professionally,
there may be value in leveraging cross-platform frameworks
and tools.
So I'll just give you a sense of what they are,
what platforms they support, what languages
and what skill sets you might need.
But, you know, knowing how to do something natively,
it's a fantastic skill to have,
but also there may be business reasons why a cross-platform
framework or tool makes sense.
And we'll just go over that briefly.
And I'll finish out with pointing you to a whole bunch
of resources that we have for you.
So when you think about developing for Windows,
you know, obviously, we made a significant change
in the experience of Windows when a user first used it.
They're presented with a Start screen.
The apps that used to be
on the Start menu are now represented as tiles.
And these are, in many cases, live tiles.
So the tiles themselves will update with information.
It's a touch-first experience.
It's very, you know, our goal is it's very immersive
and allows a user to really get
to what they want to do very quickly.
I'll demonstrate some apps for you to show you that.
Another key point from a developer's perspective is
that we provide new language choice.
So you can develop natively on Windows and on Windows Phone
in C++, in C#, but also in HTML5 and JavaScript.
So that, you know, opening up the platform natively
for web developers was, you know, a big shift.
And the way we do that,
I'll describe what the platform architecture is a little bit.
But the bottom line is there's a common runtime.
So regardless of what language you use, you have access
to the full API set natively.
So it's really about it.
It's a skill set decision for you.
So, let's demonstrate a couple of apps for you
so you get a sense of, you know,
when you're targeting the Windows platform,
how do you really differentiate your app from others.
So first off, you know, this is the main Start screen
in Windows 8.
I'm running a-- this is an ASUS ZenBook Prime Touch
so it's got a touch screen.
I can see all my apps, I can easily scroll through them.
With touch, I can pinch zoom, in this way,
I can see all the different categories that I've defined.
If I want to run an application, let's say I want to go
to the Microsoft Store, I simply touch it, or of course,
I could click it with the mouse.
It's-- and one other interesting thing
about the platform is everything
within Windows is still fully functional
with keyboard and mouse.
But we've made it also a very,
very good touch-first experience.
So now, I'm in the store.
And if I was interested in purchasing Halo:
Spartan Assault, you know, I could go in here
and I could check it out,
I could see the different screenshots, I could look
at reviews, and so on.
And I could choose to purchase it
which in this case I already have, so it knows that.
Now, from an app developer, one of the things I might wan
to do is make sure that the tile itself is providing value
to the user.
So you can have what's called the live tile,
and there's a couple examples here.
You see some tiles updating with the different images.
You can see the store title is telling me
that I have an update.
So these are things that you, as a developer,
can take advantage of.
The user could choose to turn that off or turn it
on at any time, but it's something
that if you are providing say status of your game,
you might want hotlist what the recent high score is,
or maybe if it's multiplayer game that might want
to tell the user it's their turn,
you know, it's a chess game.
The person you've been playing with has made their move, now,
it's their turn to go in and play the game.
So you could actually do
that without the app actually running.
So it's pretty powerful.
Another thing that you can do is you can provide different
tile sizes.
So, on Windows 8, we give you the option of a wide tile
or a standard 150x150 tile.
It's another way you can differentiate.
You don't-- the wide tile optional, but it's--
you supply that if you want to provide
that capability for the user.
Now, let's see.
[ Pause ]
Let's go here.
So this is the Allrecipes application.
So this just gives you an example of sort
of the design language that we are promoting with Windows 8.
It starts with it being chromeless.
All right, so what that means is you're not seeing any
decoration, let's say operating system window decoration here,
right?
Traditionally, in Windows, if you opened a window
like on Windows 7, on the desktop, there would be an edge
to the window, there would be Minimize and Open
and Close buttons on the upper right-hand corner.
There might be a menu across the top.
There's a lot of stuff going on in this window.
Here, the philosophy is content is--
content of the app is the centerpiece.
And so, you see very vivid, you know, images being used.
The user is guided through this application.
They navigate through it with-- by the use of topography.
So, you know, really nice looking fonts,
different sizes mean different things.
I'm interested in recipes that deal with bacon, all right,
so I know I can just click on that, I can touch that.
And now, I'm seeing all the recipes that match
that particular category.
If I want to go back, I can see in the upper left-hand corner,
little bread crumb arrow.
I know that I can navigate back to the main screen.
So there's a lot more to that design language.
We refer to that as modern app design.
I think initially when we released it, we referred to it
as metro design, but now it's modern app design,
and if you going to design.windows.com,
there's a great deal of documentation
on this design language.
It's guidance on how to make a really beautiful application
on Windows.
Some of the other things this app demonstrates is the
integration with the operating system itself.
So, I just swiped from the right-hand side.
I brought in what's called the Charms Bar.
So, this is also a capability as a developer, you have accesse
to this platform features from your application.
So, for example, Search.
If I click on Search,
what you'll notice is the Search layout panel comes in.
And Allrecipes is selected by default.
So, if when I do a search now,
I'm going to be searching Allrecipes.
But you can see that there are number of other applications
that have registered themselves with Windows
and are making themselves available for search.
But if I was interested in cookies--
[ Pause ]
-- in All recipes, that search is now being--
that search query was just passed to the application
and the application then decides how it wants to deal with it.
So, any application can tie
in to the search capability that's built
in to the operating system.
Something registers itself as a search target
when the user types in terms, so,
your application could do that.
All right, so you could just tie in that feature.
And the same with sharing.
So, this says this app can't share, all right?
So, this app hasn't implemented this feature.
But what you could do in an app
that would share is it might say,
"I'd like to share whatever information's on the screen,"
in which case, it might be interesting to see if I go
into a particular recipe if it allows me to share.
There we go.
So now that I'm on a particular recipe, it says--
in Allrecipes, user says, "I want to share this recipe."
Well, what comes up are all the applications
that have registered with Windows
that support sharing as a share target.
So, Allrecipes doesn't know how to share with Mail,
doesn't know how to share with OneNote, or SkyDrive.
The operating system knows how to do that.
Allrecipe is simply saying, "I want to take this information
which is this recipe and share it out."
And the user gets to choose where they share it.
So, that's another way that you can differentiate your app
on the platform, take advantage of search and share.
Now, Allrecipes, that's a great example of an HTML5 application.
That was built in HTML5 and JavaScript for Windows.
An example of a game that's built in HTML5
and JavaScript is Cut the Rope.
So, it's a popular game.
So, it's on all platforms.
It's available in the browser.
What this team did is they took their HTML5 and JavaScript code.
In about two weeks, they had it running on Windows 8,
very early on in the beta timeframe.
So, you know, just to give you a sense of, you know,
the kind of performance that you can get,
I'm going to embarrass myself and try
to play this game here so.
[ Pause ]
Here we go.
Two out of three.
It's OK. Here we go.
That's HTML5 and JavaScript.
Pretty performing, that's because you--
whether you're building a C++, C#, or HTML5 and JavaScript,
there's a common runtime for all those languages.
Now, you could actually build and you can get closer
to the metal and go C++ native, in which case,
you are not leveraging that common language runtime.
But, you know, for most cases, for most applications and games,
that's actually quite sufficient from a performance perspective.
If you're writing something like Halo Spartan,
then you're probably, you know, and you're doing 3D modeling
and things of that sort, you're going to be right
on the metal with C++.
Here's an app that's written in C#.
This is Cocktail Flow.
So, this is just also showing you, you know,
that design language I talked about earlier, its guidelines.
The-- as a developer, you get to decide how you want to implement
that particular-- you take that guidance
and apply it to your app.
And here is an example
where we've got this really just beautiful immersive application.
It looks great on that big screen.
And, you know, maybe you're interested
in how you make this particular [inaudible].
You can see the nice animations, fantastic imagery.
And it's very fast.
We used to-- when this first came out, you know,
we would refer to apps like this as fast, fluid,
immersive, and beautiful.
That's really at the core of the philosophy
of that design language.
[ Pause ]
This is a game that's built in C#.
[ Pause ]
I'm not saying that all the power of this
but you're the sense of-- that this is a-- let's go.
One more. At last.
All right.
Very sad. But, the point is you can build apps,
you can build games, you know, in your language of choice.
Now, we make that possible as I've said earlier
because we have this common run time Win RT, Windows Run Time.
And on top of that, you have your choice of language,
C or C++, C Sharp or Visual Basic, HTML, and JavaScript.
There is something called XAML,
Extensible Application Markup Language.
That-- that is the language that you would combine with C or C++
or C Sharp or Visual Basic that does the layout of the UI.
So, you can think of it as equivalent to HTML--
that HTML with JavaScript, XAML with C Sharp.
That's the same relationship there.
[ Pause ]
So, what I want to show you now is if you're interested
in getting started to build an application
for Windows, what do you need?
When we start with Visual Studio?
Visual Studio is the development tool-- you're students, so,
you have access to Visual Studio at Professional at no cost
through our DreamSpark program.
So, if you're not signed up at DreamSpark, please do.
In fact, in the Applied Sciences and Engineering Department,
you actually have your own DreamSpark Premium
and you have a web store.
So, does this class know all about that?
>> They--
>> Plugged [phonetic] into that?
>> They don't but they do now.
>> They do now?
Beautiful.
So, I don't know what the URL is to the Harvard Web Store,
but if you go there, you can get access to all
of our products at no charge.
We'll make that available to students.
So you're in Visual Studio.
You want to get started.
Well, I'm going to go ahead and click New Project.
And the first thing you'll see is the way
that we organize the templates is by language.
So, I've got Visual C Sharp here,
but there are other languages and I can expand that.
I could see-- here's JavaScript.
So, if I wanted to build an app for the Windows Store in HTML5
and JavaScript, I could start with one of these templates.
All right?
Let's say grid app.
I'm going to say, "OK.
I want to get started.
I want to build an app that's based on that grid layout
that I saw with all the recipes.
It was very similar to Cocktail Flow.
I want an app that sort of looks like that."
It started with that template.
So now, it's going to generate that solution.
It's going to give you essentially all
of the scaffolding for that application.
And by default, these templates used--
what we call Model View ViewModel.
So, it's the variation on Model View controller
but the ideas that, you know,
Model View that's the user interface layout that's done
in XAML or be done in, you know, HTML and CSS.
And then, there's the ViewModel, that's the data that you want
to bind to your user interface controls.
All right.
So, that's sounded [phonetic] by, you know,
what David had said earlier in the beginning of the class
that you're familiar with Model View controller,
so, Model View ViewModel.
You'll feel very comfortable.
Same concept.
So here I am.
I've generated this HTML5
and JavaScript Windows Store application.
I'm going to go ahead and just run it on the local machine.
See what I get for free.
[ Pause ]
Starts up, this is the default splash screen.
Here's an area you're going to want
to have some focus on, right?
Having a great looking splash screen is key.
Now the app is running.
So by default, you get a template that's laying
out some pseudo information in groups.
And if I were to click on to a group header,
I would see this view just showing me the items
within that group or I could click on a specific item
and now I'm looking at that specific item.
So there's all place holders for the data that is going to light
up your application, all right?
So, you can see this is--
this is certainly not ready for the store
but all the scaffolding is in place,
the navigation is in place.
What you need to now do is come in, apply design,
and bring in the data of your application, that's going
to be something I'll focus on when I talk
about using these open data APIs.
But the bottom line is you get a pretty functional starting place
for your applications.
[ Pause ]
As I file, new project again--
so that was HTML5 and JavaScript.
Now if I go to C-sharp, Windows store,
I can see I've got those same templates.
I have a blank.
I have a grid.
I have something called the split app.
So let's do grid in C-sharp.
I say OK. I'm really going
to get essentially it's the same application,
but now the language is C-sharp and XML.
[ Pause ]
If I say go ahead and run this
on the local machine again I get this default slash screen.
The app is up and running, looks identical.
All right.
[ Pause ]
Now we also support building for the phone.
So we're on to that, I'd say OK, I want to do let's say C-sharp
for Windows Phone, and now here are all the different templates
that I could use for a Windows phone application.
So say I want to do a Pivot App.
Let's say OK.
What platform?
Is it the Windows Phone 8 or is it 7.1?
I'm going to choose Windows Phone 8.
Say OK.
[ Pause ]
And right there in that Window you can see there's--
this is the XAML which is defining the layout.
Here is the WYSIWYG editor,
so I can see exactly what it looks like.
And if I wanted to see, you know,
want to dive into the code.
I could open up the source file, and dive in.
I'm going to go ahead and run this.
So what you're seeing here is we're emulating the phone
to get, you know, it's actually running as a virtual machine,
and it's running the Windows Phone operating system,
and but it's fully integrated,
so I can actually, you know, test it.
There-- I can test it with touch.
I can test it with the mouse.
And there are also some additional things I can do let's
say like, you know, Pivot.
So if you wanted to make sure
that your application will respond to the user,
putting the device into landscape mode,
to make sure the user interface responded
to that, you could test that.
[ Pause ]
Any question so far?
Go ahead.
[ Inaudible Remark ]
Right. So the question is,
if I'm targeting the Windows platform and take advantage
of some of the things that differentiate the app
on Windows, the Tiles and Search and Share,
those things aren't unavailable on the other platforms,
you know, how do you plan for that?
How do you deal with that?
So later in the talk, I'll inform you
on all the different ways you can build cross-platform apps
and games.
And but one of the things that you'll learn is that especially
in the area of apps, is the one thing you can't really replicate
going from one platform
to the other is the user experience, that is the UI.
So the first step in your architecture is separation
of concerns, that's for model-view-controller comes in,
or MVC as-- MVVM, I'm sorry, that we promote.
The whole idea is separating the UI layout, UI logic,
middle tier logic, data access,
make sure you've got good separation in your code.
So when you go to do something in a cross-platform project,
not all your code can go cross platform.
Typically, what you have is you try to target the majority
of your logic is-- that's not user interface-related,
that can be cross-platform.
You try to choose a language
that will get you cross-platform,
that's the other thing you have to look at.
But typically, you'll do unique UI implementations
on every file, because each on has their own controls,
their own idiosyncrasies, their own features
that you're going to want to leverage.
So it's a great question.
[ Inaudible Remark ]
The short answer was no.
The shorter answer is, it's like anything else in, you know,
I've been doing this a while.
The classic consulting answer, is it depends,
that's how you start answering any of those questions, right?
And so, you can take as a skill.
Put that on your resume.
You know how to say it, it depends.
It just buys you time as you try to come up with the answer.
So if you're ever in the consulting situation,
you could start there.
Yes?
[ Inaudible Remark ]
Right. So, you know, both Windows 8
and Windows Phone have support for sensors, for obviously touch
and dealing with accelerometers and gyroscopes,
cameras, those APIs exist.
What's-- When you start to get into that part of the API,
that's probably where the majority of differences are
between developing for Windows 8 and developing
for Windows Phone, 'cause when you start to get
into hardware-specific areas like that.
A large percentage of the capabilities between Windows 8
and Windows Phone are shared, there's a shared core
which I believe is actually is a good lead into my next slide.
Between Windows 8 and Windows Phone, there's a shared core,
probably gets you about 80 percent commonality.
But when you get into things that are specific
to the hardware, it's just going to be different.
You know, how you deal within accelerometers on--
in the Windows Phone space work that's dealing with the phones
from Nokia, and you know, HTC and other phone manufacturers.
And then, you know, on Windows, yes we have a camera, we do,
you know, we handle-- we have sensor support and so on,
a whole another set of hardware vendors.
We try to abstract as much as possible, but that's sort
of where the differences lie.
So again, separation that concerns is key.
When you're designing how, at the implementation,
you know that's the kind of thing you want
to encapsulate a way into a class library.
Make sure it's something that's architecturally a little more
plug and play.
[ Inaudible Remark ]
Yes?
[ Inaudible Remark ]
It's a great, great question.
So the question is, if I already have an app for the browser
and I'm using, let's say a jQuery
and maybe some other JavaScript libraries,
can I get that to run on the Windows 8?
The answer is yes.
So it's their-- well, I should have started it.
It depends.
Well, the answer is yes.
It will work.
Is it going to be just move your code over
and hit run and it goes?
No, so what you're going to need
to do is first determine any third party JavaScript libraries
you're using, do they work on Windows 8?
Most do, jQuery as an example, it just works.
If you want to use jQuery for doing AJAX calls, no problem.
The Microsoft has libraries, JavaScript libraries
that you bring in to your project
that give you access to the WinRT APIs.
So you'll need to add that into your project.
You need to decide how do you want to--
where it gets interesting is dealing with scaling your UI,
so that it, you know, has the look and feel
in a Chromeless function on Windows 8, right?
So you might have to adjust some of your style sheets
and things of that sort.
How do you want to integrate with Search and Share,
that's calling a specific Windows API?
You'll do that through Microsoft JavaScript libraries.
But the third party libraries for the most part,
we've seen that they just work.
So a lot of them already test it.
People are already using them.
There's probably a lot of documentation on the internet,
how that's being used.
So, the story there is it's a pretty good story.
In fact, a guy in my team by the name
of Jesse Freeman who's a really well-known
in the Indie Game Development circles, he builds games
in HTML5 and JavaScript.
And he actually teaches students who want to build games
in HTML5 and JavaScript.
He teaches them first to build it in the browser and then,
the last class, they move it over to Windows,
they get it running and they submit it to the store.
So, so he's got it down to a science on the gaming side.
You're using Canvas or if you're using, let's say, ImpactJS
or what's another one?
CreateJS is popular for doing HTML5 game development.
They just work, so.
>> [Inaudible] It's got to be possible to know that, right?
It's not just fully innovative view.
It's really native.
>> It's really native.
Where you would want to use PhoneGap which is, again,
another great choice if cross platform mobile--
if you are HTML5 and JavaScript and you want
to make sure you're going to work
on all the platforms then PhoneGap is a great choice.
If you want to take your existing browser,
HTML5 JavaScript browser code and just get it running native
on Windows, that's another choice, and you might decide
to do that but then use PhoneGap for iOS and Android.
So, you-- these are all business decisions at some point, right?
If you're in a startup, you're in a company and they're trying
to make decisions on investing time and money
into building mobile applications and which platforms
to support, this is exactly the conversations that go
on in the design meetings.
And so, it's good to kind of think through those things,
maybe learn all the different ways to do it as you're doing it
in this class and maybe in your own copious spare time.
Try out all these different approaches
and you'll learn a tremendous amount
about what each platform can do, what each, you know, framework
or tool like PhoneGap can do.
Where is the gap in functionality and so,
that's just tremendous value that you bring to whoever,
you know, future employer might be.
Differentiated apps, by that we mean taking advantage
of live tiles, right?
On the phone, you can actually have your app be available
on the lock screen, also on Windows 8.
There's a-- the ability to build applications that take advantage
of the web camera and do things
with the lens, integrated wallet.
Of course, if you're a game developer,
there's an opportunity to be branded Xbox.
All right, so we work with independent game developers,
game studios and if-- you can always reach
out to the Xbox team and say, "Hey,
could you take a look at my game."
And if they like it, they license it, you get to brand--
you get that nice little Xbox green bar
across the top of your game.
That will push more downloads than anything else.
It's that, you know, that little sort
of "attaboy" from the Xbox team.
So you'll drive a lot of attention to your app
if it's tagged with Xbox.
So, I'm going to dive back into Visual Studio in a bit.
What I want to go over is building apps
that use these Open Data APIs.
We have discovered that mobile developers who are learning
to build for the various mobile devices that are out there,
a lot of times, you need some ideas.
And Open Data APIs provide you a ton of ideas.
Let me just-- I don't know
if you've ever been out to this site.
Let me go to apihub.com.
You go to apihub.com and you could search
or you could browse by category.
You know, they've got
over 13,000 Open Data APIs registered here.
So if you're looking for data,
because the data is really what makes an app interesting, right?
And so, if you're interested in building an app for healthcare
or education, or you know, you want to use, you know,
government data, you want to--
you know, you want to integrate maps into your Mashup App,
this is the place to go
and at least get started finding what you're interested in.
So, I want to build an educational application.
I want to use REST protocol.
I'd like it to return JSON because that's--
and there I've got, you know,
I've got the Khan Academy has an API.
DonorsChoose API, Google Books API, TED API, hey-- I'll start--
you're starting to get some great ideas.
Yeah, I'd like to build a TED app, right?
So, maybe I want to mash that up with Bing Maps or Google Maps
or something like that, right?
You create a really interesting application.
The data is what makes it interesting.
So, learning how to develop
against these Open Data APIs is another very marketable skill.
[ Pause ]
Once you've identified-- where do I [inaudible].
Let's go here to Mashery.
Mashery is a partner of ours.
They-- there was called an API curator.
Go ahead and sign in.
[ Pause ]
They've got over 50 APIs
that they helped customers build and host.
And one of the ones that I've worked with is Rotten Tomatoes.
So I've just logged in.
You can see all the different API keys I have.
So once you start to work with these Open Data APIs,
there's some things you need to know about.
them. Many of them require you to get a developer key.
It usually doesn't cost anything.
You just have to register and then they give you a key.
So, for example, if I go to the dynamic documentation here
for Rotten Tomatoes, which is movie information,
I've logged in so they know what my key is
and I've just selected my developer key.
And now I can use this API Explorer
which is in the browser.
It's just a browser app and I can say, "OK, I'm interested
in building an app using the "In Theaters Data".
Let me go ahead and try it.
I want to see how this works.
So I try it out and what I see is-- zoom in here.
You can actually see what the API that they just fired,
what it looks like, it's a URL and it's got some parameters
on it and it ends with my developer key
so they know who's making this call.
And--
[ Pause ]
-- they send you back, you know, what the data would look
like which is right here.
So again, I'll zoom in so we can see it a little better.
This is the data coming back and it's coming back as JSON,
JavaScript Object Notation.
So, why does it do that?
Well, APIs that are on the internet are architected
to return very chunky data.
Think of this, if you wanted to write an app that went
and built a list of movies that someone could go see
in a theater, would you want to make a call and say, "OK,
give a movie," and that's one call.
Now, make another call, give me the second movie.
Now, give me the third movie, and you're doing
that on the internet and you know how internet connectivity
is, you know, only at the very beginning
of what the capabilities of that are
from an infrastructure perspective.
It's not always perfect.
It's not always fast.
It's not always there.
So, chunky data makes a lot more sense.
Go get me 16 movies, all right, at a time or 20 movies at a time
and not only that, not just the name of the movie,
give me the title, the year, the rating.
Give me critics' consensus.
Give me the release date.
Give me a synopsis.
Give me movie poster thumbnails.
So, it's pulling back a ton of information.
Who are all the actors in the film, right?
That's chunky data.
That way, you can make one API call on this, you know,
not very reliable internet connection.
Get back a lot of data and now use it in the app.
That makes a lot more sense.
So, this is the classic,
they used to call it chunky versus chatty, right?
We want our Open Data APIs to be chunky.
Another thing you need to be aware
of about these APIs is they are sometimes throttled,
which means the folks who are hosting these APIs
and they're providing all these data for free,
you get a developer key but they might tell you,
you can only make two calls per second and no more
than 10,000 calls a day.
That might be one level of threshold.
Another one might be you can make, you know,
five calls per second but you're limited
to a hundred calls a day.
And if you want to do more than a hundred calls a day,
you need to pay us, right?
So there're those kinds of scenarios as well.
So do your research into the APIs you're interested in using,
determine if they are bottlenecked in anyway,
there's a threshold, a cap.
Is there a cost?
You know, what do you have to do to get a developer key?
But then, once you figured that out, you say, yeah,
this is a reasonable API.
It's open.
It's free.
It's not throttled, you know.
I can build an app and I can get a thousand people using my app
and all calling that API and I shouldn't have,
I shouldn't exceed any threshold.
That's kind of where you want to be to leverage these APIs.
So, I found my API.
I'm happy with the threshold limit.
Now I want to build an app.
[ Pause ]
So, the place to start.
[ Pause ]
When I go ahead and run this application,
at least you'll see what it looks like.
Then I'm going to come back and we'll walk through it.
We'll probably set some breakpoints.
So, another thing I'm pointing out here,
this is the Windows 8 emulator.
So this is another way to run and debug your Windows 8 app
so we have a phone emulator,
we also have a tablet emulator that's built into the tools.
So, you can run the app.
I could run this app locally on my machine
but I could also test it in this simulator.
So again, I can make sure that I could simulate touch
and I could change the resolution.
That's another nice feature of this.
Windows runs on a lot of different devices.
You want to make sure that if you're building an app
for Windows that it will work on anything from the size
of a surface all the way up, you know,
to one of these, all right?
So, built into the simulator is the ability
to change the screen resolution so you could actually see
if your layout is working regardless
of what monitor the user happens to be using.
So, here I am.
I just made that API call to Rotten Tomatoes
and I got back a bunch of movies which are in theaters
and I could select one of those movies and now I can see,
you know, before I got a thumbnail of the poster, now,
I can actually see this movie poster
and I'm getting a synopsis and the rating
and the audience score.
So I didn't have-- I pulled that data all the way back, right?
So, it came back.
It's in my app.
I'm now running-- you know,
working with this data completely locally
on the device.
And I can say, now I'm interested in some reviews.
Now, I'm going back out to the internet.
As soon as I said, I want to, you know, look at some reviews
of this movie, what Rotten Tomatoes gave me back was a link
to another API that I can invoke to get a list of reviews.
And then, for each review, now it's actually a webpage.
So I'm trying to connect to the New Yorker right now
and hopefully, that will come up in a second.
But I can see the list of reviews here
on the left hand side then I can actually read the review
of the Despicable Me now in the New Yorker, all right?
So that's what the app does.
[ Pause ]
So the way I built this app is I--
one of the nice things about Rotten Tomatoes,
they actually give you nine different APIs that you can use.
The way they design them though is pretty clever.
Every API returns the same format of data.
So this is an interesting thing.
Another interesting thing you'll find when you start to dig
into these Open Data APIs, some of them are well designed,
some of them are not, or some of them just have--
they weren't able to do something maybe based
on the data they're returning.
That is as clean as this.
So each one of these APIs and I've got them documented
in my code returns the same structure.
It's a list of movies as you saw before
in that JSON that I showed you.
I've also written a sample app that uses Edmunds which is
if you've ever been to Edmunds.com,
that's where you can go look up new
and used car information, right?
So they have a developer API.
Their developer API is one of the most complex that I've seen
because they have a vehicle API, they have a dealer API,
they have a deals API and they have, I believe, a reviews API.
And then, so each one of those APIs is actually a collection
of calls and each one of their calls returns a
different format.
So you actually have to study each individual API
and determine what the structure of it is to be able
to deal with the data.
So again, just be aware of that.
So, I have defined the APIs for Rotten Tomatoes.
I've got them all defined in here
so I can actually change this application to not show
in theaters information.
I could change it to show DVD top rentals.
So, how would I do that?
[ Pause ]
Well, let's see, the best way to understand this is
to probably set a few breakpoints.
So let's see, we're going
to set a breakpoint right there, and right there.
So this is the point in code where I'm actually going
to invoke the In Theaters API.
It's defined as a string.
The next thing that happens is we take that
and we use an object in the Win RT class library
called HttpClient.
That's the class that allows me to invoke a URL.
So I simply instantiate that and I call the GetStringAsync
that makes that API call.
We'll set a breakpoint here as well
so we can see what comes back.
The next thing I do-- now remember that comes back
as JavaScript object notation.
It's going to come back as a string, a giant string
that has all that movie information on it.
So how do I deal with it in my application?
The first step I have to do is just something called
deserialization and there's a library that does it for me.
It takes that string and it will deserialize it
into an object model in memory for me.
So, the only extra work I had
to do is actually define what that object model is.
Well there are tools that do that for you automatically.
So you don't have to necessarily write that code.
But once that code is generated, you end up with a class
that looks something like this.
So I've got Rotten Tomatoes movies, has a collection
of type movie and a movie is made up of an ID and a title
and a year and a rating and a run-time.
This is as all that same information you saw
in the JSON, right?
But now it's represented as a C# class.
And so the deserialization process takes the string of JSON
and turns it into a run-time object model based
on this class structure here.
One line of code does that, all right?
You simply have to have the class to define
and there are tools that generate it for you
and it's this line of code right there
that actually does the work, all right,
so we'll walk through that.
Now when a-- remember we're using Model View ViewModel,
right?
But what I get back from Rotten Tomatoes is not a ViewModel,
it's a data model.
So now that I have all this movie information,
it's extremely rich, it's more information than I want to put
on the screen and it's not in the format that's bindable
to the user interface controls.
So I have to map from the data model to a ViewModel and then
after that one line of code binds it to the UI.
So I have to define my ViewModel.
So a ViewModel would look something like this.
It's a movie.
Well, and this is the reviews, let me scroll down,
I'll get to the movie, information will start there.
I have a movie item.
It's derived from this base class.
Now what-- why is that?
Let me scroll up because I scrolled passed it already.
On Windows, what makes a class bindable is
that it implements the interface INotifyPropertyChanged.
Model View ViewModel means that you put your data in the form
of a ViewModel, you bind it to the UI control,
it could be a list view, it could be a drop down,
a combo box, a grid control, something like that.
If the user interacts with it and changes it,
you want your ViewModel to be notified
that the data has changed.
If your program changes the ViewModel,
you want the Model View to be notified that the data's changed
and update automatically.
All of that machinery of keeping the Model View in synch
with the View Model, the Model View in sync
with the View Model, is handled automatically by the platform,
whether your HTML 5 and JavaScript or your C# XAML,
C++ that's handled automatically.
You simply have to derive from the right, you know,
implement the right interface.
In this case it's INotifyPropertyChanged.
And there's the implementation.
So now that that's implemented, I can now derive classes
from this base class that are my ViewModel and that's all
that that's going on in this particular file right here.
So if I come down, where was I?
Movie item, all right?
So here's my movie item that's bindable and it simply got--
it defines the data that I want to be able to put on the screen
and then accessors, get and set accessors.
That's it, very straight forward code.
And I'm being instant message by someone out at corporate.
So I'll just ignore that.
So let's see, so that's the ViewModel.
The last thing I want to show you is, OK, now every thing's
in the ViewModel then what happens?
Well, when that call returns all the way back up to the--
to my user interface layer, I'm going to end up here
in the response from the call.
I'm going to get the data.
I'm going to copy it from the data model to the ViewModel
and this is the line of code that binds it to the UI.
We take all the movie data
and we simply say it's the default ViewModel for this--
let me bring up this particular UI layout
which is implemented in XAML.
[ Pause ]
There's the binding definition right there,
collection view source.
So that's one of the nice features
about the platform is a lot of that plumbing,
all that capability that you expect these types
of applications to have it's build into the framework,
the class libraries that we provide in Win RT.
You just need to know how to wire it up.
When dealing with open data APIs.
You're going to make a call, you're going
to get back that string of JSON.
You're going to deserialize it into a data model.
You're going to map the data model to a ViewModel
and then simply-- and then your binding code will pick up after
that and you've got it on the screen.
[ Pause ]
Now, I wanted to show an app that was built that way,
but it's in an HTML 5 and JavaScript.
Now, this is not my code, I'm going to do my best to try
to at least point out a couple of interesting parts here.
Interesting in JavaScript that whole, you know,
invoking the API and getting back that string of JSON
that doesn't happen in JavaScript, why?
It's coming back in JavaScript logic notation.
So the nice thing about calling these APIs
from JavaScript is you get back an object model by default.
In C#, I have to map the string to an object model.
So it's one extra step in the implementation.
So here's an example of invoking the Meetup API in JavaScript.
Let's see if I can find the call.
[ Pause ]
I'll make sure I'm in the right places
and so this is not my code, here we go.
Get upcoming meetings.
So here's the API call that we want to make in our app, right?
It's in-- it's just a URL.
And we're setting up the parameters
and this is the built-in-- you could use, obviously,
you could use jQuery to do this using Ajax call.
But if you're using the Win RT JavaScript libraries you can
just use WinJS.xhr.
You give it the URL, the response type,
and then of course what code follows is the code
that is going to deal with the response.
So you can see we're just dropping into a foreach loop
and then we're just gathering the info--
he's just gathering the information about each
of the Meetups and he's putting it into the right collections
that will be bound to the UI controls is exactly the same
pattern that we did in C# and XAML
but this is just using HTML 5 controls, CSS, and JavaScript
to do the implementation.
If I go ahead and run this--
[ Pause ]
Here we go, so he's gotten back Meetups near Boston filtered
by keyword JavaScript.
And if I click on one of this it gives me a nice map
and is also going out and he's using,
this is a feature of Bing Maps.
So he's-- he is going to mash up between Meetup and Bing.
And so the Bing Map is showing you all of the coffee shops
that are near where the Meetup is happening, all right.
And so Bing has points of interest API.
So once you have the geolocation of the Meetup,
Meetup will give you a longitude,
latitude for the Meetup, you can use that with Bing to say,
give me back a list of points of interest.
And so that's the mash up he's doing here.
So again, interesting data makes for interesting applications.
[ Pause ]
And the last thing I'll show you before I go into the last part
of the talk here is-- that same pattern,
same capability is available on Windows phone
because I told you I did an implementation
for Edmunds, car data.
So that's what this application is doing.
It's going to go out to Edmunds.
It's going to get first a list of makes Acura,
Aston Martin, Audi and so on.
And if I'm interested in Audis I can click that
and I'll get a list of the models, so that came back
from Edmunds, and I say, you know, I'm interested in A8.
It's then going to show me--
hopefully it will go back out to Edmunds and get me the images
of an Audi A8 so I can salivate over them.
My ultimate goal is to start a transportation business
like Jason Statham that's just a dream of mine
to be a transporter so anyway.
You have to know that movie I guess to get the joke.
No problem.
So we have the same capability in Windows phone, any questions?
Very good.
So this is just a visual of that pattern that I talked about.
We invoke the API.
It's an asynchronous call.
That's also important.
These calls you make this open data APIs
and we fully support an asynchronous model
on the phone and on Windows.
It's an asynchronous call that means you're--
the user is not waiting for that call to return.
They can keep using your app, they can go use another app,
and then when the call returns,
your application will be notified.
That's where you'll do the deserialization.
If necessary copy to the ViewModel
and then bind to the UI.
And we did all of that.
So now I'm just going to dive
into this cross-platform app development
landscape discussion.
For C# developers, this is one of the best options you have
out there for a cross-platform support for iOS, for Android,
for Windows is with the tools and the frameworks from Xamarin.
They're actually based-- they're headquartered here
at Harvard Square.
The founder of this company is Miguel de Icaza,
he many years ago when Microsoft open sourced the .net framework
and the C# language and standardized it, he took that
and he created that implementation from Linux.
And so he's been making his living building cross-platform
tools and libraries based on C# and the .net framework for--
it's going to be 10 or 12 years now.
And the latest incarnation is Xamarin
and they provide a cross platform framework
for targeting, you know, all the mobile platforms
and the nice thing here is-- to our discussion earlier,
you can get 60, 70 percent code reuse.
Their model is, you know, port the business logic,
the cloud integration, the database access, that's portable
but do your user interface natively for each
because there's no substitute
for a native UI, there just isn't.
This has been something we've been trying to solve
and computer science for many years.
You can go back to the '80s.
There were companies that were trying to spin
up cross-platform UI, frameworks, and tools
and they began to be called--
they were referred to as least common denominator or LCD
which meant they were the poorest implementation
on every platform they ran on, all right?
So that's not where you want to be.
You don't want to be least common.
You want your app to sing
and to just be the most fantastic experience
on whatever mobile device that's on.
But at the same time, if you want to have the farthest reach,
the most opportunity for downloads and for monetization
and all of that, you want to be on as many mobile platforms
as possible so you need a strategy.
It might be native on each platform, that's a strategy.
Could be crossed platform with something like Xamarin
which means you're going to develop in C#
and you can actually do debugging in Visual Studio
for Android, and for Apple, and for Windows
so it's a great development experience.
They've got a great product here.
A lot of applications are beginning to take advantage
of that, earlier stated, your HTML5 developer, phone gap,
fantastic option for a cross platform solution, all right.
[ Pause ]
If you're a game developer,
Unity just released their Windows 8 Windows phone support
for Unity.
So you can now, you know, take your--
we're actually told by Unity that about half the games
in the iOS store are built with Unity.
So we know there's a lot of Unity developers out there.
It's a great tool.
It's on the high end but, you know,
under the covers it's C #. It's actually using the cross
platform implementation of C#
that Miguel has it designed years ago.
So it's called the Mono Framework.
And so you can build games that target all the platforms.
There's another framework, this one's very interesting.
It's called MonoGame, again same community, you see those kind
of a-- when the C# world,
if you want to go cross platform you're working
in what's called Mono.
So it's MonoGame or it's the Mono Framework which is used
by Unity or it's Zemuron which is using Mono
and its implementation.
So it's having a lot of impact.
MonoGame is a cross platform implementation
of Microsoft's XNA Framework.
So if you're familiar with building games for Xbox
or for Windows or Windows Phone, the framework was called XNA.
The cross platform version of that is MonoGame
and there are games like ARMED!
that are in the Windows 8 store that are built on MonoGame.
I'd built one myself and put it in the store,
works incredibly well.
It's very straightforward way of doing game development
and it supports Android and iOS and Xbox
and Windows and you name it.
[ Pause ]
If you're an HTML developer and you're a game developer,
you might want to look at something
like GameMaker Studio from YoYo Games.
This is a cross platform game development tool.
It will generate HTML5 and JavaScript and allow you
to target all the different mobile platforms.
[ Pause ]
There's another one like that, that's called Construct 2
from a company called Scirra.
We actually use this in all of our game workshops.
With students and professionals we use Construct 2.
That's because the free version is very, very powerful
and you can publish to Windows Phone and to Windows 8
with their free edition.
You have to understand that each one
of these tools showing you has a cost to it.
This one, what's nice about is no cost
for targeting Windows at least.
If you get into iOS and Android then there maybe a cost
to getting that export capability turned on, all right.
[ Pause ]
Another one's called Gamesolid.
You see there's several of these, all very similar.
They're all leveraging HTML5 in JavaScript
in the code generation.
But the act of building the game is drag and drop,
that's one of the nice things about these tools.
You're not in the code, you're--
if you're a game developer you want to focus on the artwork,
the assets, the sound, the gameplay, the heads up display,
the layers things like that.
That's what these tools are good at, they give you an IDE,
you lay everything out, you say what the rules are of the game,
and then you test it in the browser,
and when something doesn't work just right,
you don't go change code, you're back into their tool
and you're modifying properties of objects,
some things with that, so it's all visual.
If you are into the code then another choice is create JS.
This is a suite of JavaScript libraries
that help you build games.
There's one example out there
that does a complete implementation of which is got
to be about 15 or 20 different Atari games.
All done in the-- they run in the browser,
they've also imported to Windows 8 and this is the bit.ly.
It's kind of cryptic.
I didn't come up with a proper name but it's bit.ly/R--
capital R3, lower case v2, capital D capital H.
And at least you'll get to the website and you can check
out all the apps there that have been built with CreateJS.
There's also one of-- a member
of the team built the Catapult Wars and did it with CreateJS
and put that into the Windows 8 store and there's the bit.ly
for that if you're interested in reading up on how that was done.
[ Pause ]
I'll make these slides available too after.
Another game development framework is impactJS
and a guy-- I told you about him earlier, Jesse Freeman who is
on my team, he's on New York,
he wrote the book called 'HTML5 Game Development.
Iit's all about how to build HTML5 games using ImpactJS.
He's built-- he's just got tons of sample code online,
he's got a book, he's quite good and he has a bunch of games
in the store right now.
His favorite is, you got that he likes that old 8 bit look
and feel to the artwork.
So he creates a lot of his own artwork
and builds these games using HTML5 and JavaScript.
And he gets them running in the browser
and then he gets them running on Windows
and now he's forwarding them to the phone.
[ Pause ]
So just to close out, so I'm right at time,
is I want to make sure you know about DreamSpark.
Now if you go to DreamSpark.com, you could register there
but it sounds like what you should do is find out the URL
or the Harvard DreamSpark site.
And if you go in there, you can get Windows,
you can get Visual Studio, you can get SQL Server, you can get,
you know, everything but an Xbox all right?
You can get basically all of our stuff there.
So download the development tools, download the SDKs.
You also get a free Windows 8
and a free Windows Phone developer account that's a 150
dollar value.
All right, so students get account for free.
I want to make sure you guys get access to that.
App builders are site for developers.
If you go there and register build.windowsstore.com,
there's-- you can earn points, you can register your apps,
they can send you on some quests and you'll earn, you know,
you'll earn points to be able to win stuff.
There's also a ton-- a ton of training material up there
if you're looking for either apps or games.
Some other training I found that might me, you know,
really applicable to what you're doing now is there is a C#
fundamentals online course set of videos
and then there's also Windows Phone 8 for beginners.
So if you're just getting into the space, you just want "Hey,
I just need to learn some C# and I need to just get started
with Windows Phone," those two resources are fantastic.
And then the work I was showing you is a project
that my team did called APIMASH which is at aka.ms/apimash
and that will take you to GitHub.
So we post all of our stuff up on GitHub.
So we've got a bunch of StarterKits up there.
If you scroll down, we have StarterKits for Windows
and for Windows phone and we're actually expanding this list.
So everything you see here is being ported over the phone.
But we've got active access on Chuck Norris StarterKit,
Earthquakes and Bing Maps, Edmunds, Facebook, Foursquare,
Instagram, Meetup, Messier Sky Objects, Rotten Tomatoes,
Stack Exchange, Tumblr, Twitter, Univision, Wikipedia,
World of Warcraft, Yelp and ESPN.
All of these are all functional Windows 8 apps with the code.
And everything I showed you,
that's the pattern they're all using.
That whole open data API call deserialize bind to the UI.
If you're interested in seeing how you get started building
for Windows 8 and for Windows phone,
these are fantastic resources here all built by my team.
So it's all creates up on GitHub.
The way to do it is you just go to that site
and click the download zip file.
So we also include a Lab Workbook,
there's three Lab Workbooks in there just to kind of take you
through how to get started with this stuff, all right.
So I want to make sure you are aware of that and with
that thank you very much.
[ Applause ]
>> Thank you so much Bob.
We've been deposted at C76.net, an instructions
for how you can get access to a DreamSpark account--
>> Beautiful.
>> -- so actually you can get that
and then we'll post the slides later tonight.
>> Fantastic.
>> Thank you so much.
>> Thank you.
>> Why don't we go ahead
and take few minute break here while Dan get set up
and then we'll transition to the third and final platform
for the evening, Android.
[ Pause ]
All right, we're back so the third act here is Dan Armendariz
who actually started this class several years ago.
What's the origin of C76 can be traced back to him
and a colleague of his and it was--
I came along a year or so after that
that I finally got involved.
So everything you've seen thus far is all traces back to Dan.
So, Dan is going to look at Android develop fellows
and without further ado, Dan Armendariz.
>> Thanks.
Hi everyone, it's nice to be back.
So, speaking a note in a contact and from
where you're sitting it doesn't really seem that way.
The cause is very different back then.
Just like mobile development has really evolved over the years.
In fact in the best years since the last time
that I actually co-talked this class with David.
Android development has gotten a lot better in at least
in the initial set up.
So, we're going to talk about as quickly as we can.
We're going to try to shoehorn what I use
to put four weeks worth of content into 1 hour.
So, please allow me simply way
as I go a little quickly through some things.
Of course if you have any questions,
you can interrupt it anytime and hopefully we'll be able
to get you guys comfortable in such a way that you'll be able
to do some Android development soon as you go home.
So, just that I can sort of get a sense of where everybody is.
How many of you used an iOS device
as your say primary phone in iPhone?
That's just about everybody.
Now, is-- are there any of you that using Android device
as your primary phone?
OK. So, for those of you that have your hands up,
is that constant, do you always use
that device rather than an iOS device?
All right, so, for those of you that had your hands up,
you probably are familiar with the differences
between the experience
of an android device and an iOS device.
And this is actually really important is that.
In order to develop on one of these platforms,
it really is useful to have a sense of what
that platform is actually liked to be able to use it.
And so, if you are serious
about actually doing cross platform work just
to reiterate comments that the [inaudible] the first hour,
it's really helpful to get a sense of that experience
at how you actually want to replicate
that on this other device.
And even though Android is considered
to be the primary competitor to iOS, it's really difficult
to put them I think on that same sort of comparison, they operate
in very different ways,
they have very different reasonings behind very different
decision that went into their implementation.
And there's a lot of maybe let's see,
what is the proper word to use here.
There's perhaps a lot of difference
between the two that's in a large confusion between the two
that really just arise from this sort of basic differences,
this basic differences that arose initially
from when Google was first started developing the Android
and when Apple first started developing iPhone and iOS.
So, this is actually pretty important for us
as well as developers.
So, for us as developers, what are some of the differences
that we typically hear about the--
about developing for iOS versus developing for Android?
If you were to go out unto a tech blog and read the comments
that people always post whenever Apple
or whenever Google updates one of their hardware devices.
People always complain about the same sorts of things, right?
What are these differences?
What do Android users dislike about iPhones
and what do iPhone users dislike about Android, any ideas?
Yes.
>> [Inaudible] you know just like how as a [inaudible],
you have much limited perspective on iOS rather
than Android before functionality that [inaudible].
>> So, perhaps if I could summarize that in a way to say
that people consider Android
to be a little bit more open than iOS.
And so, that is certainly true in many respective in for us
as developers when you'd create the developer account
with Google, you pay a one time 25 dollar fee,
you have an account with them basically that 25 dollar fee is
to weed out to people that just want to create, you know,
flood the store with spam.
It's not a terribly high fee
but it is one fee that you have to do.
But then after that, you're free to submit your applications
to the store, there's no review process
and you basically create your application, you publish it
to the store and then that's it, it's up and ready
for people to download.
That's just one sense
that Google might be a little bit more open than Apple
but there's others other ways as well,
you have a little bit more control over your phone,
some people would argue a little bit more customization whereas
in iOS they tried to really funnel you towards a certain
types of experience which in itself I'm trimming not
in the sense this is a negative but in fact that is a very--
again, a very different way of thinking about this.
Google allows you to have a lot more options, and so it can
to people who are mot familiar with the system appear
to be a little bit more complex.
And so, again, this is just that same sort of idea that we want
to point out the differences between the two,
you have a question or a difference?
>> [Inaudible] are the open source in any way?
>> So, for the longest time Android was open source
but they have in fact to close source to some of them.
So, a lot of the code is in fact open source
but I think a lot some of that now more basic functions are
in fact closed source from Google.
Yeah, that was also a primary difference between Apple
and Android again, part we could perhaps include this
within this openness aspect.
What about other things, anything else as developers
that might be different?
Yes.
>> iOS [inaudible] might say
that Androids were fragmented [inaudible]?
>> Right. So, there's-- this is definitely a big one
that we hear a lot is that this fragmentation
in Android devices.
And in fact this is a very important point that I want
to bring up right a way, is that's there is some truth
to this in what is actually fragmented.
There are many different types of hardware devices available
for with the Google operating system
with the Android operating system
from different manufactures
where as Apple only is the only manufacture of iPhone and iPad.
There are many different manufacturers
that use Android as a platform.
And even within that context,
many people don't update their software as much as we
as developers might want them to.
And there's a variety of reasons for this.
Some of them may not be aware that there is an update.
Some of them-- but I think one of the more pressing problems is
that with many of the third party phones that come
out that have Android on them, they have a lot of stuff to it.
Sort of like when you buy a PC and has a lot of stuff installed
and my friend just bought an Asus and he said they would have
like a-- on my gosh, I wish I could remember exactly what it
was but it was like an Asus internet connection help wizard
or some sort of very specific thing that he was kind
of surprised that they actually bother this one,
[inaudible] company actually bother
to create the software report
and it's sort of a similar thing.
A lot of these companies will
in fact add their own additional UI components on top
of the Android base OS which further adds to perhaps some
of the confusion between different users when you pick
up an android device from say Samsung
versus one that's Google create with just the base Android.
OS it might actually look different even though it has the
same version of the OS because of these additional little
flares, you know, the additional pieces of software
that they will actually add on to this.
Now, I don't want to confuse the issue with all that stuff aside,
one of the base issues in this fragmentation argument is the
bit-- just the wide range of versions that were installed
on hardware devices right now.
So, this is a chart that Google actually created.
They released a similar chart every half month or every month
or so, showing the distribution of devices that connect
to the Google play store which is the equivalence
of the App store on iOS.
And as we can see here, there's really no one slice of this pie
that makes up the majority of the devices.
It really runs the gamut from ginger bread right here
which is a version two of Android OS
which is now several years old all the way up to jelly bean
which is one of the later versions, version 4.1 and 4.2
and now there's an even newer version 4.3 but I'm not sure
that any devices have been released
to actually have that through that.
It's actually been released at this point.
Now, sort of the saving grace here with this is
that if you did want to target a lot of this users,
you can actually create of course an application
that is targeted at one of this APIs, one of this earlier APIs
and be able to get a large portion of the market.
And by the market I mean the available market
for your application.
Of course if you wanted to use some API that's only available
in some later version of the OS,
then you will perhaps limit yourself in terms of the market
that is available for that.
But the Android OS isn't the only reason why this system
might be considered fragmented.
We also have things such as the screen size and the density.
Like I s aid the actual hardware devices are very,
very different.
And this is just-- I intentionally left out some
of the explanation of some of this but just to show you
that this is really all over the place.
That screen size on the left and screen density on the right
and Google goes through on the web site on differentiating all
of this and sorts of the exact pixel dimensions
and the exact number of dots per inch in each
of the densities here.
But really we can see that we have a problem and that is
that if you want to create an application
for an Android device that should work
on a multitude of devices.
You do have to contend with this issue
that there are many different types
of devices running many different types of OS's
that have very different hardware capabilities.
Now, to Google's credit, they have done everything
that they can to try to combat this issue.
They really try hard to make it possible for you
to create an application that can run on a lot
of this sorts of devices.
And in fact, one of the ways that they are able
to do this is is through this inclusion of resources
within an application.
So, there is an-- we're going to get a little bit technical
at this moment before we kind of come back a little bit wider
and talk about what exactly-- how exactly this works.
Oh, and looks like a font is missing here.
So basically, application resources are stored
in a resource folder, so it says RES.
And there's a variety of different folders,
it's a hierarchy of folders, and within that, there's a variety
of other directories that you can include
like a drawable directory
which will include bitmap graphics or XML graphics.
And there's also a layout
so that you can actually add layout information in XML form
or you can also add many definitions
in a menu directory as well.
And what's really neat about this set of directories is
that not only can you localize strings,
but also you can modify the name of the directory itself
to [inaudible] OS of what sort
of resources are included in there.
So, let's say that you create a game for instance.
And in that game, you have perhaps a variety of assets,
a variety of graphics that you created for different devices.
Perhaps you've created some--
well, it's something low resolution graphics
for the lower DPI-- the lower DPI devices
or perhaps you created some really high risk resolution
graphics for the larger screens or for the devices
that have very, very high DPI available.
And what you can do is very much in the style of a CSS selector,
which you might remember from your token web developments,
can you actually add some properties to these folders
which are again not intentionally masked here
but you-- we'll hope we see them when you download the PDF
when it is posted on the website.
But you can actually add CSS style selectors or--
I don't actually don't want to say that.
There are selectors in style of sort of CSS in the way
that you can have these different selectors
to target specific hardware devices or specific OS versions
within each of these folders.
So, it becomes a little bit better.
You don't have to release different versions
of the same application, but you do as you can imagine how
to create different versions of these assets
for these different devices.
And even though there's the arguments, well,
iOS is now fragmented between the iPad, the iPad mini,
and the iPhone and the older versions
which did not have the retina displays.
And all of these different things is really not quite
as bad as we have here on Android, this is an attempt
on Google's part to make it a little bit better.
Now, these resources are in fact included
within the file that's called an APK file.
An APK file is in fact your Android application.
And what's neat about this APK files
that you can actually download an APK file on to your computer,
you can rename APK to .ZIP, unzip it
and see what the contents of that application actually is.
It's kind of an interesting thing,
you can actually see the resources
that are available there,
anything that is not been compiled
that becomes very easy to look at.
You can't look at the original source code of course
because it's been compiled and then included
within that ZIP file and package into this Android format
but you can in fact look at some of the resources
that are available within that one file.
So, this is important to realize that we have this APK file
which is in fact this application
that we want to ultimately create.
Within an application, we have these resources.
Again there's-- you can create resources that are generic
so that it would apply to all hardware devices
or you could even make them very specific
by having multiple drawable directories
for different resolutions or for different density screens.
And you can create different strings directories
for localization, international localization and so on.
But really, the heart of all of the Android applications comes
from this one XML file called Android Manifest file.
The Android Manifest file basically tells the system,
the Android system when it is launching your application,
what it should expect, what is the name of this application,
what is the minimum version of the OS
that I can run this application,
what are the different screens called activities
that might be available, what are the permissions
that this app requires, does it require phone access,
does it require access to my contacts,
does it require GPS access, all of those sorts of things.
So, the OS parses this information
and will make a determination,
the OS will actually decide whether or not it can install
and run this application based on the limits that you set
in this XML file and also the limits of the device.
So, perhaps the user rejects your permissions
because you want to do all sorts of things on the user's device,
you have-- your permissions are too lose
and they decided that's actually not quite a good thing to do.
Well, you can modify all of this information here
in your own application towards that end.
Now, one of the things that is really important to realize
about this as well is that you'll notice that here, we're--
we define variety of things, but within this application,
we actually have some components.
Now, in this simplified version of the XML file,
we have a single component called an activity.
And this-- when we start to talk about activities,
this is where really starts deviate from the way
that we would expect it to work
if we only are familiar with iOS devices.
In Android, it's really difficult for us to talk
about an application as a single all enclosed app
that runs entirely with your code.
It is possible for instance, if I am creating a--
let's say that I want to create an application
that perhaps uploads some photos from your phone
up into-- up to the web.
Perhaps I have a photo sharing services some [inaudible]
and I want to be able to take your photos from your phone,
user selected of course, upload them and share them on the web.
So, perhaps we would create this application
to actually pull the user's photos
which everyone they select from their photos app
and then upload those on behalf of the user to the internet.
What's interesting about this is
that we can actually have a very simple UI that presents the user
with a couple of options saying, OK, we'll what, log in first
and tells what album you want to add these photos to.
But when the user actually goes to select the photo,
we could in fact launch an activity
from an entirely different application,
perhaps the photo application, and have the user select one
of those photos in that other application.
Is this relatively transparent?
What the user sees is that they open up your app,
there's a couple of options, you have to have to log in
or do whatever then they click a little Choose Photo button
and it appears seamless to them and that there's another window
that appears on top of that UI
that they are previously interacting with.
So, it appears as though it's one application,
but now all of a sudden,
it's a photo selector probably different application
all together.
Now, this sounds kind of convoluted
but there's a great power to this
and that we can generalize them, we can have this--
this become very generalized if you wanted to include,
say drop box support in your application.
You could actually make sure
that the drop box application was installed and asked drop box
to run the log in activity
and have the drop box application deal entirely
with the authentication mechanism or perhaps you want
to have your users be able to select one contact
out of their contact list rather
than fetching all the contact information and displaying it
to them, you can in fact ask the contact application itself
to show the contact list
and have the user select one of those context.
So, we have to differentiate between this idea
of an application which is what we would create
and would be always self-contained
and what the user would actually run.
When the user actually runs this application,
it becomes a slightly different turn that Google likes
to use called the task.
And the reason that is called a task [inaudible] applications
because this task could actually run multiple applications
[inaudible] to the user.
Again, in the same context whereby they start your
application and in this application, we want the user
to be able to select a photo.
So now, we have our application running
and they see this one activity.
By the way, an activity is just a screen interface to the user
that the user have actually interact
with one screen is essentially one activity.
So, we have our own activity here.
Now, our application request
from the photos app, the photo selector.
And so now, another activity comes over then masks the one
that we had below but, we have two applications running.
So, this is the difference
between the task in an application.
Application is what we are creating and is something
that we are-- that we are eventually going to run.
But you have to realize that activities are not necessarily
so specific to your application that it's only run
by your application, depending on the properties that you apply
to this activity it's possible for you to create an activity
that someone else's application could then run.
So, again the example here would be say, a contacts application
or let's say that I am creating the new social media platform
or what have you and I actually want the user to be able
to select one of their contacts from the Android device
and rather than create a contact list
on my own I can just request from the contacts app to show
that contact selector, that contact list
and have it return the data to my application.
So, this is just a difference in terminology, a difference
in implementation, already this provides quite a lot of,
a lot of power and a lot of openness.
Notice that in-- I never said that--
well, maybe I did say but I didn't mean to say
that there is the contacts app, there is one built
in contacts app that you always have to use.
Due to this sort of open nature of Android it's possible
to create a competing contacts app place it
on the Google Play store and that's--
and then your users could then interface
with that contacts app, with that new contact app instead.
So, rather than when my application request a contact
from the contact list, rather than go
to necessarily the default application it could provide the
user with the choice.
Well, I see you how multiple contacts apps installed
on your device how or rather which application do you want
to use to select this contact?
Perhaps another example would be let's say that you just have a--
an activity that's very simple which has URL on it,
you click on that URL, you don't want to--
you don't want to implement an entire web browser yourself,
and so you figure OK, well now I can just launch a web browser
activity from another program to show that webpage to the user,
you can imagine this-- you can envision the scenario
where there's multiple browsers installed on this computer
or a computer yes, but also on this device,
there's multiple browsers installed and perhaps Chrome,
perhaps Opera, maybe some others as well
and you could provide the user
and by you I mean this happens automatically the--
by the user clicking on that URL and you requesting
from the Google operating system
from the Android operating system that you want
to open a URL it might realize, oh hey, there's two programs,
there's two applications that actually support this type
of data, which one do you want to use?
Do you want to use Chrome or do you want to use Opera?
This can then select one of those two options and proceed
to show that that information, that webpage or that webpage
in whatever browser they choose and again it appears
to be relatively seamless,
it doesn't look its swaps applications to this other--
to this other web browser it instead just loads an activity
in front of the one that you are using.
So, there's a variety of-- there's a variety of components
that can be part of your application,
the activity is sort of the simplest one in the sense
that it-- this is that UI that the user is going to interface
with and what we are going to see in some code examples
in little while or just various forms of activities,
but there's also different types of components that exist
in an Android device as well.
So, these activities, single screen with the user interface
if you want have multiple screens you certainly can
but that means that you're going to have multiple activities,
that's not that big of a deal it's just sort
of an interesting thing to note.
Another type of component that you could have is a service
which would be just the background task
for long running operations, let's say that you want
to upload some information to your web server,
let's say let's go back to that earlier example
of having this photo sharing website and I want
to have the user selective photo and be able to upload it
to my website, if it's a big photo we can run a service
that uploads it
in the background while the user does other things,
we don't have to be bother with it.
Another example of a service might be music player,
you might have an activity that actually is the interface
to that music player with play, pause, stop, volume, control,
forward, backward, so on, and so forth but the actual playing
of the music occurs in the service which occurs
in the background which allow you to change tasks,
again this word tasks which would allow you to change task
so they could go their web browser and continue listening
to music from your same player.
Now, there's a couple of other things
that that could a little bit more specific but just listed
in the interest of completeness the content provider is a way,
it's just of a standard interface
for applications to access your data.
So, if I actually wanted to pull some data
from a common application like contacts
or photos this is separate from the idea of actually bringing
up activities, but maybe there is some interface
that I actually want to expose to allow other applications
to access the data that my application will actually
create, content provider is the way do that,
broadcast receivers response to system-wide announcements.
So, the tone will actually broadcast to all
of the applications that the screen has gone,
the screen has gone dim or that the battery is running low,
or that the white Wi-Fi has been turned on of off, or a variety
of other things and even applications themselves can send
broadcast to the entire system as a whole and you can define
which if any of these that you're interested
in actually respond to them which is kind
of an interesting thing, allows certainly a bit of power
in what your application can do.
Now, activity is meant to--
because it's user facing it's going to be given a lot
of priority by the Android OS whenever is actually being run.
So, this would get a fair amount of CPU time as, you know,
Android OS has been-- has allowed background applications
and background task to be run for quite a while now and one
of their solutions was
to prioritize what the user is actually interfacing with.
Services, they'd also tend to be prioritized relatively compared
to some other things but not quite as much
as the user facing activity if they're running out of RAM
for example perhaps it will free up some services
that were running stale or running
that the user wasn't actually using.
Content providers and broadcast receivers these are smaller
things, but they're meant to be very lightweight, they're meant
to be-- this is something that's happening as a result
of this system call, so let's get it done quickly
and be done with it.
Are there any questions on this so far?
I realized this a little abstract, mostly in attempts
to point out some of the differences between the way
that iOS would work compared to how Android actually function.
Oops, so how then do we actually create one
of these applications?
Well, the short answer is that you go to developer.android.com
and this actually for you
as an Android developers you're home based,
there's an enormous amount of information here,
the API documentation, there's a lot
of updates whenever new versions come out, there's a lot--
I mean there's just a wealth of information that's fantastic,
you can also download the SDK from this website.
You'll notice if you go to the website though
that there's two versions of the SDK,
there's software development kit, the SDK
and the native development kit, the NDK.
The native development kit is a bit lower level, it allows you
to write high performance applications in C or C++
and basically embed them within an Android application.
We're going to essentially ignore the NDK,
but if you are interested
in high performance native applications because you need
to create a game for example
of very graphics intensive game then you might pay more
attention to the NDK, but for the vast majority
of us we don't really care about that, it's nice that it's there
but we're not going to quite use it,
the software development kit is the way to go.
So, there's a couple of things to note about the SDK,
first when we create an Android application we're actually
writing code in Java, the end result isn't the Java program
and I'll explain more about that in just a moment, but the code
that we write is actually in Java.
We use and we can use if we want, again as part
of this openness, that slightly more open idea we could use a
variety of different development environments,
the one that's recommended in that would actually include
with the SDK if you download it as a clips,
you could just use plain text files if you wanted you can kind
of do it however you want but you'll notice
that using a clips tends to be the fastest
and the best option for us.
So, what then-- how then--
what is the process for us to build an Android application?
I mentioned that we have to write the code in Java
and there is a few important things that are--
that distinguish this from Java and I'll point those
out when we actually look at a hello world example,
then we have to compile this into some Java bite code just
as we would a regular Java program,
but Android itself doesn't actually run Java code.
In fact the Android platform is a modified version of Linux
that runs something called the Dalvik Virtual Machine.
So, whereas in Java, it actually runs a Java Virtual Machine
to run and execute the Java bytecode
that has been compiled by the Java compiler.
Google has created a slightly different version
of this virtual machine that is a little bit more--
well, it pays more attention to things like memory usage
and CPU time and is a little bit more fair with regard to all
of those things because in this mobile environment we have
to be very careful about battery usage and the amount of time
that we spent in each of these applications.
So this bytecode is converted to a Dalvik compatible executable
which is basically just the modified version,
again, of this bytecode.
It is running in essence Java bytecode
but it's been converted,
some things have actually been changed
to be compatible with this Dalvik VM.
So, it's derived from Java but it's not exactly the same.
But this process allows us to write the code in Java
and then creates and compiles it
into an application that's actually run and understood
by this Dalvik VM within the Android Platform.
Now after that we have to package it
up in a special way using Zip in a tool called AAPT
which actually includes some of the--
well actually pre-compiles some of the information
that we have including the Android manifest file
and variety of other things
and actually creates an Android package.
So, you might remember that--
I said before that this has gotten a bit easier.
Well, it's always been a little bit easier than is,
as if you are kind of the hard--
the hardcore hacker person that loves to do everything manually,
you can certainly do this.
But for the rest of us you can just download the SDK
which includes Eclipse, the IDE,
and also the Android tools plug-in, the ATT plug-in
and allows you basically just to go straight
from the code directly to the end result, the Android package.
You can find all of these on developer.Android.com and one
of the ways that it is much easier now is
that they actually package all of these up into one download,
that means so much easier.
Before it was really a pain.
You just download Eclipse and then you had to download the SDK
and you had to download the Eclipse plug-in and you get all
to work together but luckily we don't have to do that anymore.
It comes in just one nice package, makes it very easy
for us to do development.
So, again, if you're actually interested in this,
go to the website developer.Android.com/sdk/index.
Download the SDK and that's it,
you pretty much can get started with it right away.
So from here, how do we actually create an application?
Well, of course, the HelloWorldApp is the--
well, the simplest thing that we can do
to actually create an application.
And there's a couple of things that I want to point
out about the code in this HelloWorldApp and I'm going
to switch here to this other screen
because it has better text color
and it makes it a little bit easier
to take a look at what's going on.
So, the very top of this Java file, we basically have a couple
of things, one is package information.
How many of you have developed for Java in the past or at all?
Pretty much everybody, OK.
So for those of you that haven't, it's very similar
in syntax to C or C++,
but of course there's a variety of differences.
It's going to be very heavily object-oriented.
I'll try to point out as many differences as I can.
But I don't really want to do a Java primer right now.
There's-- If you do a search
for Java tutorials you will find some very excellent tutorials
by Oracle that talked a little bit more about this.
But we have to put all of this code into the scope
of a package, into a particular name space,
and so that's what we are doing in this first line.
Then we're going to import a variety of libraries
that actually make it possible for us to run this code--
the activity library which we just talked about and couple
of other things we're sure actually required for us
to run this, the bundle is required by the OS.
This log one-- is it really required unless we're doing
logging which there's some very basic logging at the very bottom
of this of code which will occur
in just a second and also a widget.
You can maybe guess by the name what this actually does
but it's essentially this, it allows you
to place a text object on the activity and allow you
to view some text on that, on the screen.
So, that's just all sorts of some initial setup that we have
to do and this is the contents of the code.
Now one thing that you'll notice for those of you
that are Java developers that's very different
from other things is that there's no main method.
There is no method that makes it very obvious
where we're actually starting the application and the reason
for that is that the main method is done
by the operating system itself.
What the OS does is it looks at the manifest file
that we've actually created.
And so this is a full-pledged Android manifest file
that has been not reducted for simplicity.
So we can actually see how some of these things work.
Again, notice that this is the manifest XML element,
uses a minimum SDK version of 3 which is now ancient.
There's no need for you to use version 3,
just like Android 1.5 or something.
So, only if you want maximum compatibility do you really need
to do that.
But even then there's problems using minimum SDK version of 3.
It implies certain permissions
that are not necessarily what you would want.
I think it wants full access to contacts and some other stuff
that if you just upgrade the minimum SDK version to 4 or 5,
then you lose a lot of these problems that actually existed.
But this is meant for maximum compatibility here.
Now, the application within the 3 actually defined
where the icon is for that app
on the home screen of the device.
It's within-- You'll notice at Drupal [phonetic].
Remember I mentioned that Drupal directory within our resources.
We can have various resolutions of our icons
to support the different density and different size
of the screens that might exist.
Similarly, can we actually apply a label to the name
of that application within the string resource and provide--
you'll notice that here we're looking for specific resource
within the string directory called an app name which--
you'll just have to-- you'll just have to trust me for now
that says something in English.
Now, if we skip this and go down to activity,
notice that we have defined one activity here.
And within it, we have this idea of an intent filter.
And what this intent filter actually does is it notifies the
OS what's this activity should actually do and there's variety
of filters that we can apply to it.
Perhaps we want to restrict this activity from being open
in other applications.
Remember that I mentioned that we can task,
we can have other applications request in activity.
We can explicitly disallow or allow
that with this intent filters but also we apply these
to elements to this intent filter telling the OS
that this is the main activity and this is the one
that I launched on boot.
Or on boot is opening the application itself.
And so really there's no main method that is
because we've hold the Android OS that we have this activity
and this is the one that we want to run.
Now, the activity itself-- excuse me--
the activity itself goes through a life cycles of sorts.
There're a variety of methods that allow you to run some code
when the activity is first been called upon to actually open
and then things have been rendered on the screen
and then it's finally ready for use by the user.
We're going to ignore a lot of those for now and I'll defer
to the Android documentation for you
to get more information on that.
But now we can take a look again at our HelloWorld code
and realize how this is actually working.
We have a public class Code One.
This is just the class for this one activity, extends activity
because this is in fact an object of type activity.
I actually want to create some code that launches activity
and display something to the user.
And within that we have this one method on create.
This method is invoked by the OS
within this activity object whenever this activity is
about to be started.
Let's say, "OK, I am about to display this activity
so I'm going to create it and display it on the screen.
What do you want me to do?"
It's asking this code,
and by asking means invoking this method,
which allows our code to actually create the layout
and apply a layout on to this activity
and then display it to the user.
So, the next few lines-- this super.uncreate, we just have
to make sure that we actually invoked the act--
the main activity classes on create method just
to do any house cleaning,
otherwise you will get a very nasty error
from the Android plug-in or from the SDK when you do this.
And then programatically we are actually going
to create a TextView that says some text.
We're going to create a TextView object.
It's just basically instantiated in this first highlighted line.
Next, we're going to set the text
to be displayed by this TextView.
And then, we are going to set the content view
which is the content displayed within this activity.
So, this is not necessarily a mysterious function call.
This is actually a function call that's implemented
by the Android activity class that allows us
to set the layout for this activity.
It's basically the layout for this activity will be what?
Any guess?
This based on this code.
[ Pause ]
Yeah.
[ Inaudible Remark ]
That's right.
So, all-- the only thing that will be on the screen,
when we actually run this activity,
will just be a TextView.
But that TextView itself is invisible.
We don't actually see its bounds.
We just see the text that's contained within it
so we should expect to see the text, oh high.
You know, there's some logging capabilities stuff down here
which if we have a little bit more time,
I would explain is very useful for us to actually get messages
from our code back in to this really cool, little section
down here, log caps which allows you to actually run.
It's sort of a consul-like way of actually being able to look
at errors from your activity.
In fact, you can see, it says, "This is an error,"
which [inaudible] or which replicates what we see here is a
very good for debugging in the Android world.
But if I actually run this code, this is what we would see.
So, very much like in Xcode how you have an emulator for iOS,
you have an emulator for Android devices as well.
So, what's cool about this is
that this is actually an emulator, the Android device,
since so I can go to the-- I can't see the--
oh, we've been bitten by the resolution bug.
There's some buttons down here that allow me to go
to the home screen and we can sort of play
around with this version of the Android device.
But personally, it's cutoff.
So, rest assured, it's there.
You can click on it, but not right now.
But what this allows us to is our HelloWorld application.
We have here our activity which takes
up the entirety of the screen.
By default, the theme was black.
We didn't get to see that, but it's elsewhere actually in--
within the package itself.
We have our one TextView,
this is our text, and that's about it.
Up here, this is just a title bar for the application itself.
It's a little confusing at first when expect to only see this
and you also see the title of the application but realize
that that is actually just the Android OS displaying a little
title above the application itself.
We could give a flag in the manifest that would request
that this activity become full screen and hide everything.
We haven't set that flag.
We've just done a very simple manifest file here.
And of course, we have our systemwide status bar
at the very top here.
Now, there're few other things that I want
to show you about this.
I'm going to make a few of these activities available
in the source code for you to download
and actually play around with.
We don't really have a lot of time to go through them.
But hopefully, if you just go through them on in a time,
they'll progress in such a way that you will be able
to hopefully start following along
as we make slightly more complicated layouts,
start adding second activities
and start doing other things with the Android OS.
But there're a couple of things that I want
to point about the SDK itself.
One of them is that this IDE again is Eclipse.
This is not written by Google but is
in fact is a larger open source project.
If you already have Eclipse downloaded
because you do development in other languages or even in Java,
you can actually download the SDK
without including the IDE itself.
You can just download the SDK to plug-in and follow some steps
on the developer website to get all of that working
in your own version of Eclipse
which you might have already installed.
But if you don't have installed already, don't worry about it,
you can just download everything and work out of the box.
Once you have everything set up though, if you go to this menu,
the Window menu, you'll notice that you have a couple
of new Android options.
And I'll zoom in here so that you can see them.
You have Android as the key manager,
Android virtual device manager
and Android lint which is a checker.
But, it's these two that we are worried about now,
the SDK manager and the virtual device manager.
The SDK manager allows you
to download different versions of the SDK.
So, if you want to build an application
against a specific API number, you have to make sure
that you have downloaded that SDK.
So, if you download all of this, this is going
to take of a lot of space.
It's several gigabytes with--
of information that has to be downloaded on to your computer.
But then you could compile your application against anyone
of these API targets and it will work just fine.
In this case because I had set the--
in the manifest file the minimum SDK version-- oops--
of 3 as we can see here.
Let's make sure that I in fact have that version installed.
And as you can see, Android 1.5 which is an API level of 3,
so realized that there're two different versions.
The public facing version is the string Android 1.5,
but the API level is in always incrementing integer
which started at one basically that earliest version
that was released through consumers was API Level 3
and it just has been going up ever since then.
So, here, we can see that I in fact have the SDK platform
and the APIs installed.
You can do that on your own
for whatever version you want to run.
But the for more fun one, I would say,
is the virtual device manager which allows you
to create virtual devices, emulated devices in just
about any configuration that you can imagine.
So, if we were to create a new device here, what this is going
to allow us to do is to create a new emulator of sorts
that replicates certain features of a device.
So, we can specify a variety of things.
We can give it a name.
So I'll just say Android 2.4 just for example.
Now, we can see here that when I click on device, we have a list
of different device sizes.
Pick your Poison, it goes all the way from the Nexus 10
which has an enormous 10 inches screen all the way down to some
of the earliest Android devices including a 240 by 320 screen.
It's pretty small.
We can select any of these and actually create emulators
that you can actually test your application
across the wide variety
of devices before you even release it
to the Google Play Store.
I'm just going to [inaudible] so I connect Nexus 10.
I can select the target.
So, this is the API, this is--
basically, the OS version that this should run
that this hardware device should run.
Now, it is possible for you to get yourself into trouble here
and run an ancient version of a target on a new device
that would not ever have that installed.
So, you have to sort of be careful here
that you select ones that would make sense for that.
Sometimes, you get the ability to change the CPU if there's
in fact an option between ARM and Intel.
Hardware keyboard would be emulating
and actual hardware keyboard on this device,
hopefully the rest are somewhat self-explanatory.
You do-- would get to set things like the RAM size,
the amounts of heap that your virtual machine would have
for this application, the amount of internal storage
if that device actually has to emulate an SD card.
And notice a couple of options down here,
snapshots which if you've used virtualization software
elsewhere like VMware or Parallels or any sort of thing,
we actually close that virtualized window.
It saves the state of the memory and will allow you
to restart it from there.
Similar thing here with snapshots,
you can actually save the state between times that you close
and then we open the emulator which is pretty good
because sometimes, it takes a while
for this emulators to load.
And, they now have also hardware accelerated GPU which is great
because before was software
and it was just-- it was jut the worst.
It's so slow.
OK, so you can create one of these
and you can have actually a variety of them.
Now, in order for you test your application
on an emulated device, you have to first-- here's the steps,
make sure that you download-- oops--
make sure that you download the appropriate SDK and SDK manager
and then create a virtual device in the virtual device manager.
Then you have an emulator that you can actually run.
So, in this case, I actually have my Android 2.3.3 running,
as you can see right here.
So, I'm emulating an Android 2.3.3 device in this emulator.
There're a couple more things I want to point out.
One of them is that there's this number
to the left of the name, 5554.
Now, this is pretty cool.
What this allows us to do is to log
in to the emulated device from our computer.
So, in this case, I can open up a terminal Window.
Type in "Telnet localhost" and then that port number.
That number actually coincides with the port that's running
within our computer or within the emulator
and is exposed to our computer.
When I hit Enter, notice that I connect to this emulator
and this is something that you can really only do
to the emulated devices.
Now, you can type "help" and you actually get a variety
of things that you can do.
So, you can actually force the emulator to change its state.
And there are variety of interesting ways.
You can have, for example, it follows a set of GeoTracks
or maybe your application is actually really dependent
on geolocation.
So, you could actually provide it some GeoTracks
and observe how your application reacts as the phone is not taken
in a physical sense but it's taken in a--
in an emulated sense though that geolocation track.
You can also do a variety of things like what happens
when I changed the network settings on it and say
that the user loses cellphone signal and they only have WiFi
or vice versa, how does my application actually react
to any of this-- to all this sorts of things.
You can also send the emulator an SMS, just pretty funny.
But it is actually useful especially
if you are creating an application that is relevant
to that, a variety of other things as you can see here.
Now, one of the really neat things here is
that if you have an Android device
and you are doing Android development, you can plug
in that device using USB to your computer and you will be able
to develop directly on to that device.
You might actually have to check all, check a few a settings
in the developer menu that says allow development, mode,
and some other things.
But what this essentially allows you to do really without having
to deal with any certificates or any or anything like that is
that you can very quickly and easily connect an Android device
to your computer and try your program not only
on an emulated virtual device, but also on your physical phone
or physical tablet as well.
And can you also run, you can also connect to it
and run a variety of commands.
It's really limited in these physical devices
because you don't have root access
to the file system unless you have actually rooted the device
which is an entirely different issue.
But even though that is an option, it's probably better
to test this out on an emulated device and see how it behaves
on the physical one, but then it certainly an option
for you there as well.
And one of the great things about the Android SDK very much
like the iOS, the iOS development in Xcode is
that once you understand these simple principles,
once you've understand Java, once you understand how
and APK is built and what its hierarchy
of files actually looks like, becomes very easy for you
to look up the APIs that are given to you
in the API documentation and quickly make an application
that you would want to run
or that you would want to deploy to users.
And so, hopefully then, this has been a good summary
of how you can actually get started with it.
So, if you are interested in this, go ahead and go
to the developer website, download the SDK and get started
on Android development.
And until then, I want to thank you very much.
I think David has couple of last words.
But that you ought for you time.
[ Applause ]
>> [Inaudible] Dan and Rob.
We [inaudible] like for a couple minutes
for one-on-one questions, otherwise,
we post it all resources from tonight.
The course's website on Wednesday,
[inaudible] we're going to dive some more
in advance, iOS [inaudible].
In Wednesday, we will gather for one last time
for [inaudible] app, so we will see you then.
[ Noise ]