Message from discussion School project help needed.
Received: by 10.52.90.109 with SMTP id bv13mr965528vdb.1.1346955676128;
Thu, 06 Sep 2012 11:21:16 -0700 (PDT)
Received: by 10.52.175.170 with SMTP id cb10ls1075307vdc.1.gmail; Thu, 06 Sep
2012 11:18:55 -0700 (PDT)
Received: by 10.58.145.167 with SMTP id sv7mr1046810veb.11.1346955535320;
Thu, 06 Sep 2012 11:18:55 -0700 (PDT)
Received: by 10.58.145.167 with SMTP id sv7mr1046809veb.11.1346955535308;
Thu, 06 Sep 2012 11:18:55 -0700 (PDT)
Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [18.104.22.168])
by gmr-mx.google.com with ESMTPS id r14si568110vdu.1.2012.09.06.11.18.55
Thu, 06 Sep 2012 11:18:55 -0700 (PDT)
Received-SPF: pass (google.com: domain of krismicin...@gmail.com designates 22.214.171.124 as permitted sender) client-ip=126.96.36.199;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of krismicin...@gmail.com designates 188.8.131.52 as permitted sender) smtp.mail=krismicin...@gmail.com; dkim=pass header...@gmail.com
Received: by mail-vb0-f53.google.com with SMTP id fc26so2067883vbb.12
for <email@example.com>; Thu, 06 Sep 2012 11:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
Received: by 10.52.18.244 with SMTP id z20mr2836918vdd.85.1346955535110; Thu,
06 Sep 2012 11:18:55 -0700 (PDT)
Received: by 10.58.95.104 with HTTP; Thu, 6 Sep 2012 11:18:54 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:18:54 -0400
Subject: Re: [android-developers] School project help needed.
From: Kristopher Micinski <krismicin...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Sep 6, 2012 at 1:37 PM, Lew <lewbl...@gmail.com> wrote:
> Kristopher Micinski wrote:
>> I should respond to your comments with the disclosure that I am
>> somewhat affiliated with a university (as a PhD student), currently
>> Maryland, and have taught or TAd a few classes here. My views are
>> from experience teaching (let's say, three or four sections, and then
>> a section of much more advanced grad students), and my previous
>> experience as an undergrad in TAing..
> I am a software developer of long standing who's worked with Java
> professionally since the late 90s, worked on many large- and small-
> scale Java and mixed-language projects, and for the last year and a
> half on Android and other mobile projects.
> My experience is from applying programming knowledge in a real-world
> environment where mistakes cost money and jobs, and the problems
> are not artificially constrained for pedagogical purpose.
> In my own experience the knowledge of Java helps to learn Android,
> but the difficulties to which I alluded are real and do impact the learning
> curve. I find that a year and a half was more than I needed to understand
> the Java parts of the platform, but evolvingly just barely enough to
> understand the pragmatic aspects of actually running software that won't
> crash and will do what's intended.
> I'm sure it's much cleaner in the ivory tower.
Well, one obvious thing that's different is that within academia (I
have worked in industry for a short time, by the way, as well!) is
that things don't really have to work, things don't have to be 100%
polished, and the professor will not go through your design completely
for a final project. Even if it's a deliverable for a final project
to a company, my experience with these "capstone" courses is that most
companies simply take the code and look at it, and then send their own
engineers to rewrite it anway..
> Sure, but it's the Android stuff that isn't in Core Java that makes the
Yes, but the fundamental stuff won't change. In my experience data
structures, algorithms, etc..., are the real content. If you need to
represent a list of things, you can do so using the standard
techniques. Students will have seen adapter classes before (for
example), if you put the two together you get the necessary
requirements for an Android list, for example. If you add in their
courses on parallelism, the concepts they will have learned in a
networking class, and others, they should be able to extrapolate this
knowledge to look at the Android task code and write a "lazy list"
that is refreshed from the network (indeed, our students did this in
our android course, I believe...)
> Humans are chimpanzees, because all the core standard chimp DNA is there.
Sure, and if you're studying biology as an undergrad, most of the
stuff you need to know lies in the common knowledge. if you're
programming professionally, it might not, but I'm still not convinced
the difference is a real killer, I'd bet if you took someone who knew
a lot about the structure of chimps, they could pick up the stuff
about humans pretty easily too!
>> separate API, sure, but the components remain the same. For example,
>> the activity lifecycle mirrors many other state machine processes
>> found in any of these other environments students will have seen
>> before. Students also will (in any good computer science program)
>> cover functional programming concepts (from this you get intents and
>> components, which are typically fairly stateless -- though not
>> *always*), concurrency (students will have seen things similar to
>> AsyncTask<> before, as most courses -- certainly ours at UMD and those
>> I took at my undergrad institution, along with the other courses I've
>> reviewed from probably six other institutions -- cover concurrency and
>> ways to make it easier), and RPC (AIDL, Messenger / Handler combos).
> Yes, but these are extra-Java data, so you are supporting my thesis
> that more than knowledge of Java is needed to be effective with Android.
You need to know more than Java to program on Android because it's a
separate API. This is the same with any other large Java framework
out there: swing, JSP, etc..
I'm also arguing that they are extra java things, but not things that
students won't have seen before: they've probably seen something
'close enough' outside of their Java courses (generally we still teach
"old world" unix IPC, for example).
>> Courses at many universities will also typically cover GUI
>> programming, typically in *more than one form*. For example, I
>> believe our courses here cover wxwidgets to some extent, and also the
>> C# GUI stuff, this fits into the more general category of reactive
>> programming, which is covered to a larger extent in our courses on
>> functional programming and theory. So I assume that a student should
>> be able to take Android's GUI system "off the shelf" and know
>> something about "widgets" (views) and things like that.
> Again, by learning more than Java in the first place.
Yes, the OP said he was a university student. Any university which
teaches only Java isn't one I'd want to hire anyone from.
>>> For example, you could go through years of standard or enterprise Java
>>> programming without every defining a UI in XML. If this is new to you, it
>>> takes some getting used to, and no amount of Java or C++ knowledge is
>>> directly applicable.
>> This might be the case, in practice the way we explained it to
>> students within our Android course was saying: think of this as being
>> compiled to some code which produces equivalent Java code which sets
>> up the GUI, or as a templated language. I know this is just one
>> example, but I would argue that similar things in Android can be
>> explained by analogy to other concepts, once students learn enough
>> material and get a feel for the space. Now, it's entirely possible
>> that students at other universities may be extremely different than
>> the ones I've encountered, but I would suspect that this isn't
>> entirely off base.
> Okay, you take the care to teach the stuff separately that isn't in the
> core standard Java. Good.
>>> If you have a year of time to do so, I'd start by doing the following:
>>> - reading the developer guide
>>> - playing with a bunch of the sample apps
>>> - perhaps buying a copy of Mark Murphy's android book (the commonsware
>>> guide) if you find yourself needing more explained examples of the
>>> API, etc...
>> You consider a year "easy to pick up"?
>> No, the "year" came from the OP's discussion that he will be working
>> on the project for a year. I did not mean to imply that it would
>> take a year to learn the Android ecosystem, it does not.
> Okay, fair enough.
>> I consider three days "easy to pick up". A year seems on the long end of
>> what it should take to be competent at Android programming.
>> I would say that by my estimates, it would probably take a month of
>> working through examples at a casual rate (i.e., if the student
>> treated a course on Android to be one of her four or five courses) to
>> understand Android enough to start being productive. However, this
>> estimate is not refined (I've only taught a few people android stuff,
>> and only have a few classes on which to base numbers).
>> I think that the Android API presents some new concepts, but nothing
>> that's so new that it's completely foreign to students. I would
>> really emphasize that all of the concepts in Android are just things
>> students should have seen in new clothing.
>> By the way, if you can find an example in Android of something that is
>> truly new, something that's really people haven't seen before, I'd
>> like to hear about it, we're always thinking of ways to reason about
>> the system and so far seem to be coming up with uninteresting stories
> Straw-man argument, so I decline to play.
> I am not the one claiming that Android is "truly new".
> Whatever the frak you think you mean by that. It smells like an empty
I'll make it easy for you, if you can name one thing in Android that
sticks out as feeling different than a professional programmer has
seen before, then I'll consider it truly new.
I don't think it's an empty phrase at all, we have trouble publishing
Android papers all the time because reviewers will say "well this
thing in Android is exactly the same as X in Java, or Y in C++, or Z
I'm not sure how it's confusing?
>> (So far the best story I have relates to writing down a dependent type
>> for intents, and the semantics of intent handlers, and things of that
>> nature, which is -- what I see -- the most interesting and novel
>> design feature of the Android framework).
> The whole is greater than the sum of its parts.
Maybe, I sitll contend Android is just an API, and not a hard one to
pick up, at that.