Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Android Programming

Developing Android Apps Visually, In 3 parts 78

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.
This discussion has been archived. No new comments can be posted.

Developing Android Apps Visually, In 3 parts

Comments Filter:
  • Re:Not worth it (Score:3, Informative)

    by tepples ( 727027 ) <tepples.gmail@com> on Saturday April 30, 2011 @06:22PM (#35987128) Homepage Journal

    Best, they will run on iOS and any future mobile device with WebKit.

    But will they run fast? When Apple decided to add JIT execution of JavaScript to Safari in iOS 4.3, only pages running in Safari got the fast treatment. Applications using a UIWebView and web sites that have been bookmarked on the home screen were stuck with the old, slow, interpretive JavaScript engine rather than running a JIT engine in a separate process.

  • by element-o.p. ( 939033 ) on Sunday May 01, 2011 @01:07AM (#35988726) Homepage
    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.

    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 :) 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 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
  • by Yvanhoe ( 564877 ) on Sunday May 01, 2011 @06:15AM (#35989626) Journal
    I love Qt creator for that. Functional UI designer a la Visual Basic, generates real cross-platform code (and I mean there is usually zero modification to make a linux/windows version work) and underneath it is real C++ you can modify. Using C or even assembler if you wish.

Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin

Working...