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 > difference. > 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 > phrase. > 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 in unix." 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. kris -- 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
