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. > Lew wrote: > > Kristopher Micinski wrote: > >> > >> I don't think that Android is a significantly new API or programming > > > > Compared to what? > > > > Compared to the slew of APIs that undergraduates will typically see. > As undergrads here (@UMD) we teach a few different environments. > Oh, I thought you were comparing it to Java in other environments. > - In our 100 level courses we teach "standard" java [sic], this includes > the standard library, but may also occasionally include swing [sic] or APIs > that the professors have home baked. > - In our 200 level courses we teach "old world" unix stuff, including > the posix [sic] API, and things of that nature - In the 300/400 level courses we have a variety of courses using > different APIs, teaching things from OpenGL, to the .NET ecosystem, > and things like that. > - We also teach theory and the theory of systems and programming > languages (through which we teach Ruby, OCaml, etc.., although more > niche languages like Erlang are sometimes used as well) > > I consider that an undergraduate from our department should have > enough familiarity with adjusting to different systems that they > should be able to take any new language, adapt to it, along with a new > API, and get productive work done without being "stuck." > > We do have a 400 level class covering Android programming, and all of > our students were able to adjust to the environment very quickly, and > start getting real projects done within one month's time. > > >> > >> environment, and if you know Java (and even if you don't, but know C++ > >> or something similar-ish well enough) will be very easy to pick up.. > > > > > > You elide over the difficulties. Java is more than a language, it's an > > environment, and that environment is quite different between Android and > > other platforms. > > > > I disagree. The core standard "java [sic] stuff" is all there. There's a > Sure, but it's the Android stuff that isn't in Core Java that makes the difference. Humans are chimpanzees, because all the core standard chimp DNA is there. 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. > 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. >> 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 phrase. > (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. -- Lew -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
