Slashdot Mirror
Developing Android Apps Visually, In 3 parts
An anonymous reader writes "Dr. Dobb's has a three-part blog (all three parts are up; this is part 1) about using App Inventor. The focus isn't so much on the technology but rather the discussion of 'can visual development let anyone program?' If so, is App Inventor really visual development? And should we be teaching real programmers about visual development. Most of the conclusions are in part 3. As a byproduct, they show you how to put App Inventor output on the Market and there are two games on the market (free) that resulted from the articles." Here's part two, to round out the trilogy.
Coincidentally I just started learning to develop mobile apps last week. I'm using Sencha Touch and PhoneGap, Eclipse, and the Android SDK. The combination works pretty nicely, and lets me build fairly pretty pseudo-native apps, working in JavaScript. Best, they will run on iOS and any future mobile device with WebKit.
My blog
...your spaghetti code will actually look like spaghetti!
Pretty good is actually pretty bad.
...don't use visual tools. They describe the GUI in assembly language, or use torturous frameworks. Of course it is this elitist attitude of making things as difficult as possible that has resulted in 2 decades of user experience that stinks. I don't know how many times I've seen programmers rant that Visual Basic was evil because it was too easy and let anyone program. They somehow think putting together a user form should require 2 weeks and multiple degrees in computer science. On the contrary, it should be ridiculously simple to throw together a user form. There are things you can't simplify like algorithms and complex logic in science and business and THAT is where you NEED to focus and concentrate a developer's attention. Bloated frameworks and non-visual building tools from hell that make things unnecessarily hard are nothing but a hindrance and should be eliminated. There's no shortage of work to go around.
These posts express my own personal views, not those of my employer
Slightly off-topic, but Android development for me has been marred by the steaming pile of dung that is Eclipse. Netbeans is ok but it's android support isn't great.
I finally got around to trying IntelliJ IDEA, and hooray! Android development is now possible on my lowly 2009 PC. It is so much better than Eclipse. You should download it now and forget about Eclipse this instant. Let's see:
Cons compared to Eclipse:
* Not the official android IDE.
* Doesn't have some android tools built in (ddms).
* No GUI editor for the manifest.
* No GUI layout editor (although the Eclipse one is unusable anyway).
* Logcat always autoscrolls. It's slightly annoying.
Pros compared to Eclipse:
* The main UI is way faster and more responsive.
* The 'smart' features (code completion, refactoring etc), are even more clever than in Eclipse -- they practically read my mind.
* No retarded 'workspace' paradigm.
* The code editor is way more responsive.
* The UI is a lot more sane, and much less cluttered, even though it still has a ton of features.
* Built-in git support. Maybe this is in Eclipse, but I'm sure it is way more complicated.
* No retarded 'perspectives'.
* The UI is cleaner IMO, although it is a little win95-ish.
* I have no idea why, but it manages to detect my phone even though adb doesn't. (I know right?)
* It's just way better. There are tons of features that make you think "Wow, they really spent time implementing that (in a good way)?", random example: if you create a new class, edit and press undo, it will ask you if you want to undo creating the class!
In conclusion, fuck you eclipse. You suck.
See, the one fundamental concept programs like this miss is that ANYONE CAN PROGRAM!
I'm sorry guys, I hate to break with the fleet of devoted programmers needing to feel like they have something on the world, here.
Programmers are no better than people in any other skilled trade. And, I'm confident that I could work in any skilled trade I wanted to. If I could learn how to program in twelve languages, who is to say that I wouldn't be a genius with plumbing, or electricity? The difference here is that I want to program applications, so I do it. People who don't want to be programmers don't. That's all there is to it. Anyone can program, and anyone can learn programming.
There's no doubt in my mind that this is development because a program is being created.
And if you're creating a program, you have wanted to create a program.
And that makes you.... a programmer.
Microsoft in the 90's showed us beyond a shadow of a reasonable doubt that no matter who easy you make the programming tools for non programmers, they're not going to use them because non programmers are devoted to the almost religious idea that they can't do it. It's like anything else that way. Tell yourself you can't do something, and you'll be right 100% of the time.
So if you want to create Android apps, create the damn android apps, but like it or not, you're a nerd now.
You're a nerd now.
Now you just need to become an expert at War Craft and Dr. Who, and you'll fit right in with the rest of us.
Later
You may now gaze upon my greatness.
I've done some work in visual languages, like Pure Data/Max mostly, and some things you notice:
It's easy to get started in them but, no matter how easy they make it, eventually you get bogged down in trying to look up the particular name for a block that does X, because any logic that takes more than two lines of real code or relies on tight loops can't be programmed literally in the visual way.
I'd say that visual languages give you a good entre to programming, but really it's just BASIC brain damage all over again -- visual languages use visual cues like lines or sockets to do what in fact are nothing more than GOTOs, you have to do a lot of hard coding, the language makes you do a lot of static decision making, you always are deciding to make (k) objects instead of arbitrary (n) objects; code reuse, structure, or metaprogramming are unheard of.
Don't blame me, I voted for Baltar.
I'm no expert, but there are 'proper' methods of handling screen sizes and scaling (as opposed to hard coding resolutions, which sadly, some devs do), and hardware variations (no GPS, etc) are relatively easy. It's a factor, but has been exaggerated a bit. Most of the things you need to check for are the same sort of things you'd do if you were following good practices developing a desktop or web application.
How many people do you think actually have an inborn ability to program?
Most people have created or followed algorithms (cooking recipies, map routes,...) at one point or other. Part of the problem is abstraction, which many are not good at, but a large portion is also the jargon that we programmers pick up along the way. For example, my dad's pretty good with logic, but I can't really explain what a "class" is to him - he didn't just spend the last decade working his way up to that concept. I'm pretty good at understanding things, too, but I would suck at his field, because I don't have the history for it either (and in his case, about 30 years of it).
But that's not the point, anyway...
Like it or not, there are now going to be a zillion devices that are a pain to type on, but still powerful enough to do some level of development with. In such devices, a properly worked-out and thought out graphical programming system would be a godsend. Remember, lots of kids are going to grow up with these devices, and not a full-fledged beige-box as the primary computer in their lives, and they're going to need a programming system on it to learn on.
Basic may not be the greatest programming language, but quite a few of us wrote our first programs with
10 PRINT HELLO
20 GOTO 10
Don't knock it - if they can create a system that makes it easy for me to code while sitting in a waiting room with the iPad or Galaxy Tab, or even my phone, I for one welcome it!
I just start playing with AppInventor this week, and right off the cuff...it's got a lot of potential, but I haven't used it enough yet to know if it's really a serious tool.
:) That's just a minor quibble, however, and while I'm enjoying learning how to create Android apps, I do have a few concerns about the language. First, the language itself is completely obscured. There may be a way to bypass the GUI and see the code AppInventor is generating, but if so, I haven't found it yet. Having spent way more time than I like cleaning up the horrible HTML that both Front Page and Dream Weaver generate when my family members who couldn't (or wouldn't) learn HTML came to me for help -- and at some point, they always came to me to fix their HTML when FP and DW didn't get it right -- I tend to distrust visual coding tools. I would also love to see a comparison between execution times for two identical Android programs, one written in AppInventor and the other coded by hand. I'm curious how AppInventor optimizes the code. Also, I find that the programs get a little hard to follow by the time you get a page full of code blocks on the Block Editor. It may be just another case of the way I think hindering my adoption of the tool, but I seem to have an easier time keeping the code in my head when I type it out by hand rather than when I snap puzzle pieces together on a GUI. Finally, my last concern about AppInventor is that the "command" reference is somewhat lacking. It took me pretty much a full day, and numerous Google searches, to figure out how to use the TinyDB to store persistent data in AppInventor. In the end, the procedure I was using to store data in TinyDB was never running because I was getting an error in the routine that pulls data from the TinyDB because the way to tell if there is any data stored in the database is not exactly intuitive and is completely omitted in the documentation.
The Cons: I tend to be kind of a linear, procedural thinker -- I cut my teeth on BASIC, learned COBOL in high school, learned Pascal and Perl in college, and now use mostly Perl and a little Python -- so AppInventor requires me to approach writing programs a little differently. For example, in Perl, if I want to compare two strings, I think it out the way the line is typed on the console; AppInventor, on the other hand, seems kind of like programming in Reverse Polish Notation
The Pros: I am quite impressed with the ease with which I started using AppInventor. When I first started using Python, it was very easy for me to read someone else's scripts and comprehend what they were doing. Writing Python, on the other hand, was a bigger hurdle. To be fair, a lot of that was because I've been writing Perl for so long, that I try to do things the Perl way (okay...ONE of the many Perl ways ) and then have to search Google to find the way it's supposed to be done in Python. AppInventor, on the other hand, is just a matter of snapping puzzle pieces together. If you try to do something that would be a syntax error in a traditional language, AppInventor immediately pops up an error telling you why you can't do whatever it is you are trying to do -- and the error messages are pretty intuitive. Procedural errors are a whole other story -- see the caveat above about using TinyDB.
Experienced programmers may turn up their nose at tools like AppInventor since it lowers the barrier of entry so much, but IMHO, tools that make it easy for people to learn programming concepts are a Good Thing. Will people churn out crappy code in AppInventor? Yep. Do people already churn out crap code in Perl, Java, C/C++/C#? Yep. Will skilled programmers make well-designed apps in AppInventor? I don't see why not. I imagine the quality of the code will probably depend upon some of the concerns I described above, but the *design* will be a reflection upon the skill and experience of the developer. I don't see any reason why a good developer will suddenly be reduced to creating crappy apps with tools like A
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
I did say first program...
I've been writing software for over 25 years, with the last 20 of them being mostly GUI based.
The visual components of any non-trivial program will compose about 10% of the final product, with the other 90% being the code that does the actual work. AppInventor addresses the least crucial aspect of writing software -- the ability to create a user interface.* The ability to think abstractly, and to implement that abstraction, is far, far more important; and it is the thing that relatively few people can do well.
So no, AppInventor is not going to let just anyone write good software. Without the skills needed for other other 90% of software development, AppInventor will do nothing more than address a trivially insignificant aspect of writing software.
* Do not construe this statement to mean that designing good, clean user interfaces is easy. It is an art form all to itself, but constitutes a relatively small portion of creating software.