Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Developing Android Apps Visually, In 3 parts

timothy posted more than 3 years ago | from the build-it-and-they-might-pay dept.

Android 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.

Sorry! There are no comments related to the filter you selected.

oh, Me first. (-1)

Anonymous Coward | more than 3 years ago | (#35987048)

Um, I got nothin.

Not worth it (3, Interesting)

pieterh (196118) | more than 3 years ago | (#35987068)

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.

Re:Not worth it (-1)

Anonymous Coward | more than 3 years ago | (#35987124)

The only gap I like is pink, hairy, and smells like fish.

Re:Not worth it (-1)

Anonymous Coward | more than 3 years ago | (#35987278)

...and it looks like this []

Re:Not worth it (0)

Anonymous Coward | more than 3 years ago | (#35987920)

Surprisingly above link is SFW.

Re:Not worth it (3, Funny)

MobileTatsu-NJG (946591) | more than 3 years ago | (#35988154)

The only gap I like is pink, hairy, and smells like fish.

Let us know when you finally found out what it really smells like.

Re:Not worth it (2, Informative)

tepples (727027) | more than 3 years ago | (#35987128)

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.

Re:Not worth it (2)

jo_ham (604554) | more than 3 years ago | (#35987166)

That is a technical issue though, and one I assume they will resolve, since it relates to security issues if they had added JIT globally with the way it is set up right now. At least, that was my understanding over why it has been brought in piecemeal

Re:Not worth it (3, Insightful)

Nerdfest (867930) | more than 3 years ago | (#35987636)

It's very sad that this is tagged 'troll'. It's currently a fact of development that will likely be addresses in a future iOS release. People are getting a little defensive about their choice of platform. If you want them to improve, help identify their flaws and stop blindly defending them. There's a pile of things that need fixing in all of them.

Re:Not worth it (1)

Anonymous Coward | more than 3 years ago | (#35989174)

Actually it's not about being defensive but providing the user with a good user experience. On iPad 4.2 I tried one of Sensa Touch demos showing full screen tap areas (chess game example) which was highlighted as the best of the best. The performance was so bad that half of the time taps were not being handled by the UI, and everything being redrawn on the screen happened half a second later. After seeing this demo I decided to stay away from it, because the iPod 1 is still much better hardware than first generations iPhone/iPod, where it would be as slow or slower.

So yeah, it's a nice thing but will get there in one or two years when mobile devices have the power and runtime environments have been optimized.

Re:Not worth it (-1, Troll)

jo42 (227475) | more than 3 years ago | (#35987272)

Hate to break it to you, but what you are building are not "apps", more like "crapps".

Re:Not worth it (0)

Anonymous Coward | more than 3 years ago | (#35987460)

Let's be realistic: Using HTML5, CSS3 and JS may not be the most respected way, but actually it's an elegant idea to write your GUI in a declarative language and separate its semantics/structure from its design. It's certainly better than manually doing it. (Or are you one of those people who think they are not real programmers if they don't re-invent the wheel? While a actual real programmer holds re-use and standardization of multi-purpose stuff highest.)

Whether you do it in XUL, QML, a self-designed language or HTML5 doesn't change much in the end.
CSS3 is superior to every of the traditional styling methods and only professional DTP systems and TeX surpass it.
And JS is a much better scripting language than the common cattle think. The newest versions are rather fun (as in Haskell-inspired) and it's in one league with Python and Ruby.

Of course you won't write tool that uses much hardware or 3D game in it (yet... there's WebGL). But if you write e.g. a phone book application or calculator in C, you're an idiot too.
The right tool for the right job. And I can see many jobs where this way of doing it surpasses all others.

Of course assuming, the programmer / designer knows what he is doing.

Re:Not worth it (0)

Anonymous Coward | more than 3 years ago | (#35988018)

But if you write e.g. a phone book application or calculator in C, you're an idiot too.

Why would you be an idiot? Because it'll be smaller, faster and lighter than your app that requires a dozen libraries and a statically-linked in library just to work?

Re:Not worth it (2)

fractoid (1076465) | more than 2 years ago | (#35991236)

No, because you'll have spent 10x as long coding something in a language designed for building 1980s operating systems than you would have spent building it in some decent modern language designed for coding GUI apps. If you did it for fun and it was fun then mission accomplished. If you were doing it to achieve some goal other than personal satisfaction, you've wasted a decent-sized chunk of your valuable time.

The cool thing about visual programming is... (2)

dingen (958134) | more than 3 years ago | (#35987070)

...your spaghetti code will actually look like spaghetti!

Re:The cool thing about visual programming is... (1)

RobertM1968 (951074) | more than 3 years ago | (#35988034)

...your spaghetti code will actually look like spaghetti!

Hey, I'm half Italian... I dont see the problem with that. ;-)

Re:The cool thing about visual programming is... (0)

Anonymous Coward | more than 3 years ago | (#35988050)

...your spaghetti code will actually look like spaghetti!

Hey, I'm half Italian... I dont see the problem with that. ;-)

With no sauce...

Re:The cool thing about visual programming is... (1)

RobertM1968 (951074) | more than 3 years ago | (#35988092)

...your spaghetti code will actually look like spaghetti!

Hey, I'm half Italian... I dont see the problem with that. ;-)

With no sauce...

Oh, screw that, then!!!

Re:The cool thing about visual programming is... (1)

oiron (697563) | more than 3 years ago | (#35988290)

Having worked on LabVIEW for a WHOLE PROJECT (stupid client insisted on doing everything in it), I agree!

If your code looks like a hairball, it needs refactoring...

Real programmers... (4, Insightful)

syousef (465911) | more than 3 years ago | (#35987136)

...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.

Re:Real programmers... (1)

St.Creed (853824) | more than 3 years ago | (#35987414)

I completely agree with you.

Most people I know that actually *have* a computer science degree, don't mind Visual Basic. They realize that underneath it all it's just another Turing machine with a better interface. Yes, you can abuse it. Just like Excel is abused to build entire BI-solutions. A fool with a tool and all that...

Re:Real programmers... (3, Informative)

Yvanhoe (564877) | more than 3 years ago | (#35989626)

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.

Re:Real programmers... (1)

St.Creed (853824) | more than 3 years ago | (#35989676)

Interesting - I'm not doing much development work in that area but it sure looks interesting.

Re:Real programmers... (0)

Anonymous Coward | more than 2 years ago | (#35992700)

You might be interested in trying Necessitas (Qt and QtCreator for Android):

See the android-qt mailing list for Windows and Mac OS X versions.

A new version should be ready soon too.

Disclaimer: I hack on this.

Re:Real programmers... (1)

Yvanhoe (564877) | more than 3 years ago | (#36034956)

Looks interesting, thanks !

Re:Real programmers... (0)

Anonymous Coward | more than 3 years ago | (#35987532)

App inventor doesn't work like that. It has nothing to do with building UIs. You should try it.

Re:Real programmers... (2)

pjt33 (739471) | more than 3 years ago | (#35989210)

I haven't used VS2010 yet, so I'm not sure whether they've fixed it, but the biggest problem with the winforms designer in VS2008 isn't that it's too easy. It's that if you touch anything it rewrites half the .designer file. Must have been implemented by someone who didn't ever look at diffs in their source control program.

Re:Real programmers... (1)

jrumney (197329) | more than 3 years ago | (#35989388)

I often saw this attitude when I was working for a company that sold a tool aimed at taking the work out of web UI building. It was very simple to convince the management of potential customers of the benefit they would get from increased productivity. But when it was passed down to developers to evaluate, they dismissed it, usually reporting back that it wasn't suitable for insert specialized backend function here rather than trying to evaluate it for the purpose it was designed for and appreciating that it would allow them to focus on the more interesting and challenging business specific details of their application.

Re:Real programmers... (1)

Have Brain Will Rent (1031664) | more than 3 years ago | (#36002526)

Maybe the developers were just tired of getting almost done implementing a system and then having marketing come in yet again and say to them "hey and it also needs to do xyz - that's not a problem to just stick that in there, right?"

Nonsense (1)

anw (42556) | more than 2 years ago | (#35992004)

Real programmers use visual tools when they are the right tool to use. If you are trying to lay out a pixel-perfect preference dialog for a retail app they can't be beat, and real programmers use them. And if anyone ever came up with a visual tool that makes the actual work of programming simpler, real programmers would flock to it; but don't hold your breath.

Programming is a process of progressively deeper understanding of a problem space. Visual tools allow you to easily represent a shallow understanding within the space explicitly supported by the tool designer, but the basic geometry of pictures is hopelessly inefficient (compared with text) at representing anything complex.

The work spent on making visual tools would be better spent writing high-level libraries for a modern language. I like google's go, but there are lots of equally good efforts out there. Given such a high-level library (which implicitly must exist to support the visual tool), the sorts of programs that can actually be expressed with visual block tools - like the one by the article writer - can be written in a short page of code, and not hit a brick wall when you need to step outside the designers problem space.

But the inefficiency of representation of visual tools is not in itself a killer defect. The real problem is that they fool novice programmers into ignoring the genuine complexity of even trivial programs, which leads to the production of bad software.

Re:Real programmers... (1)

Have Brain Will Rent (1031664) | more than 3 years ago | (#36002464)

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.

Of course it doesn't take all that. That kind of qualification only comes into play when it is necessary to put together a good user form. People who think it is ridiculously simple to "throw together" a (good) user form don't understand that even the seemingly simple is often complex. That is why there is so much crap available.

HCI, GUI design etc. does take a lot of knowledge (and experience) to get right. Where should the initial focus go? What's the best order for focus to follow as the user hits tab? What are the best colours for the form? What's the best layout of buttons, text areas etc.etc. so the user finds it a natural experience and is lead down the path which minimizes problems/errors in filling out the form? What's the best layout so that the user resizing the form still gets something that looks right and is still useful? etc. etc. etc.

IntelliJ IDEA (4, Interesting)

Timmmm (636430) | more than 3 years ago | (#35987182)

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.

Re:IntelliJ IDEA (2)

Haedrian (1676506) | more than 3 years ago | (#35987230)

The GUI layout editor which comes in Eclipse works. Granted some times you just want to type your code in yourself, but otherwise its simple drag and drop for the most part.

Eclipse's "Workspace paradigm" is very useful if you do lots of different things with it. Got bored working on mobiles, swap the workspace to your Java one and you have everything you left - settings included. Want to do something else, use another workspace. Its a great idea.

Perspectives again.. take a short while to get used to... but then you get a cleaner UI which is geared towards a single task.

Re:IntelliJ IDEA (3, Funny)

blair1q (305137) | more than 3 years ago | (#35987258)

Fuck you is a plugin for eclipse. It won't do it natively. And it's a bitch to install. Do you really need eclipse to do that?

Re:IntelliJ IDEA (1)

St.Creed (853824) | more than 3 years ago | (#35987424)

That... gives whole new meaning to the phrase "Java developers do it in Eclipse" :)

Re:IntelliJ IDEA (1)

JAlexoi (1085785) | more than 3 years ago | (#35987646)

With a lowly 2007 desktop and a 2004 laptop, I'm doing Android development with Eclipse with no issues whatsoever!(Fuck Android development, I do full blown J2EE with WebSphere development on those machines!) IntelliJ IDEA is great, but you have to adapt and actually like it. I tried it several times, but have not found the appeal... (Java developer for 13 years now)

In conclusion, fuck you eclipse. You suck. (0)

Anonymous Coward | more than 3 years ago | (#35987658)

That'll cost you extra, honey.

Eclipse works fine here, too.

Re:IntelliJ IDEA (0)

Anonymous Coward | more than 2 years ago | (#35989984)

I agree with you... Last job I was contracting for a company where they mandated using Eclipse. As a long time IntelliJ IDEA user I gave them the finger after 3 months. They lost their most senior developer. They want me back. Eclipse and CVS. Fuck that company. Fuck Eclipse indeed.

Re:IntelliJ IDEA (0)

Anonymous Coward | more than 2 years ago | (#35990414)

I heartily agree with this.

I nearly gave up programming in java altogether when I couldn't get eclipse to work right. Then I also found IntelliJ and all was right with the world again.

I have the same feelings about pydev in eclipse because it just doesn't stand up to the VERY well spent $100 for Wing IDE. (Yay for student discounts)

Re:IntelliJ IDEA (0)

Anonymous Coward | more than 2 years ago | (#35990438)

I believe you find perspectives and workspaces "retarded" because you do not fully understand them. If you are using eclipse to work on multiple projects that all require a different environment (Android, J2EE, RCP, etc.) you may find that using different workspaces helps separating and managing your configurations. Perspectives are easy to configure and can be used to have a highly focused work environment. While I agree that IDEA is an amazing IDE that is far superior to eclipse in some areas (for example grails development!) I believe that you are judging eclipse too quickly and didn't bother learning how to appreciate it.

Re:IntelliJ IDEA (1)

vinng86 (1978262) | more than 2 years ago | (#35991774)

Logcat only autoscrolls when it's not scrolled to the very bottom of the window. Move the slider and it won't autoscroll.

Re:IntelliJ IDEA (1)

Timmmm (636430) | more than 2 years ago | (#35992260)

Shouldn't it be the opposite -- autoscroll only when it is at the very bottom. And for me it autoscrolls all the time anyway.

Re:IntelliJ IDEA (1)

vinng86 (1978262) | more than 3 years ago | (#36015686)

Uhh that's what I meant haha. I messed up the order - it indeed autoscrolls while only scrolled to the bottom.

Right right right, I get it. (3, Interesting)

JerryLindenburg (2048934) | more than 3 years ago | (#35987212)

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.


Re:Right right right, I get it. (3, Interesting)

Tinctorius (1529849) | more than 3 years ago | (#35989376)

Anyone can program, and anyone can learn programming.

No and no.

I have seen many people struggling to learn PHP (as part of their education). Not because they had any issues with the language itself, but because they couldn't systematically approach their problem. And if you would have read the TFA, or even simply peeked at the pictures, you would have seen that this IDE is almost a glorified code coloring editor, where words of code fit together like jigsaw pieces.

The art of programming is actually the art of reverse-engineering: you put your program together like you take your solution apart. If you don't know how to carefully dissect your ideas, then you are not a programmer.

Just like VB? (0)

rrohbeck (944847) | more than 3 years ago | (#35987236)

The quality of those apps will speak for itself.

Re:Just like VB? (0)

Anonymous Coward | more than 3 years ago | (#35987282)

Spoken like someone who's never used it and doesn't know what it is except what s/he heard from someone in 199x.

VB's quite a bit different now than when you were a kid.

should we? (1)

blair1q (305137) | more than 3 years ago | (#35987238)

Should we teach C programmers about Assembly?
Should we teach perl programmers about C?
Should we teach SQL programmers about perl?
Should we teach HTML programmers about SQL?
Should we teach Drupal programmers about HTML?
Should we teach anyone about the insides of the things they use?

Only if we teach Assembly programmers about opcodes, I guess.

Re:should we? (1)

istartedi (132515) | more than 3 years ago | (#35987310)

Sheesh! Just teach them all Maxwell's equations, some quantum theory and particle physics Be done with it. Enough of this coddling people with circuit analysis and all that other high level stuff they've glued on top of it.

Re:should we? (1)

maxwell demon (590494) | more than 3 years ago | (#35987374)

Maxwell's equations are just a very special case of the standard model of particle physics (only the simplest interaction, operating in the classical limit). All you need to teach is the standard model and general relativity. All other established theories of physics are ultimately just special cases of those. Indeed, for computers, you can probably omit general relativity.

Re:should we? (0)

Anonymous Coward | more than 3 years ago | (#35987482)

Pfff. Adhering to physical laws is for n00bs!
I bend reality to my will. There is no spoon.

Now bend over, avatar! I'm late on my Tetris session and I need a elbow!


Re:should we? (0)

Anonymous Coward | more than 2 years ago | (#35990370)

" ... the standard model and general relativity. All other established theories of physics are ultimately just special cases of those. ... "

- "And then, something wonderful happens." :)

" ... for computers, you can probably omit general relativity. ... "

Given the present ascendance of nanotech and quantum computing, "new" quantum concepts will have to be incorporated as programming entities. Spatial and cronological locality, nonlocality, entanglement ... etc. Expect a lot of activity in the cron developer's thread. :j

How is the mayhem handled? (1)

bogaboga (793279) | more than 3 years ago | (#35987250)

I would like to know how App Inventor handles the chaos (read fragmentation) in the Android ecosystem. Chaos stemming from the different screen sizes, types, hardware especially that for processors and graphics and manufacturing quality.

Disclaimer: I am no app developer, but an avid Android fan, currently using the Samsung Galaxy S II and loving it.

Re:How is the mayhem handled? (2)

Nerdfest (867930) | more than 3 years ago | (#35987662)

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.

Yes. See... (0)

Anonymous Coward | more than 3 years ago | (#35987256)

...Open Inventor and the image analysis tool called MeVisLab ( Expensive, but best I've ever seen for RAD in this area.

From my limited experience... (1)

CaptainLard (1902452) | more than 3 years ago | (#35987292)

App Inventor seems like labview for android. That means that programmers should hate it and hardware engineers should like it. That being said, I'm a hardware engineer and I'm writing apps in java. I guess I was expecting app inventor to be more intuitive but there is somewhat of a learning curve. I figured if I'm going to have to learn something I might as well learn the fundamentals (java) so I can apply it in other places. So I decided to focus on the whole eclipse android sdk package.

Thats not to say app inventor doesn't have its place. I'm thinking its good for an intro to programming or programming for non programmers in highschool or something. Just to get kids thinking logically. Or interested in something constructive. But serious programming it ain't.

Re:From my limited experience... (1)

uradu (10768) | more than 3 years ago | (#36000800)

I played around with it some, and for anything but relatively simple apps it can get a little unwieldy, even though you can encapsulate and collapse functional blocks in their own modules so you don't have to see your entire app layout all the time. It is still awfully cumbersome to do simple things like specifying the input parameters to a function, or the conditions for a loop, things that take a second in text. That said, the main limitation I ran into was that they didn't have a proper component for web service calls, something that any connected app nowadays can't really live without. Abandoned any further evaluation when I found that out.

Anyone can program, yet again (1)

paulxnuke (624084) | more than 3 years ago | (#35987508)

I hate to just say "This is impossible, forget it and go on." I'd love to see it happen, but I don't think it ever will until we have near human level AI that can replace a human coder. Programming is not about dragging pretty blocks around, it's about visualizing and then creating a logical process that accomplishes something. Programmers have the (inborn, I believe) ability to do this; nonprogrammers don't, and no amount of training or simplified tools makes the slightest difference.

I was in college with them, the ones who never got it and repeatedly asked the sort of questions that made it obvious they wouldn't understand the answers. I've had to work with a few, too. It's pretty easy to spot, after a while.

The problem is that we're attacking the wrong problem, and the result so far has been tools that laymen still can't use and programmers hate because the pretty UI's just slow them down. That describes pretty much any system that makes you click and type stuff into little boxes instead of writing it in a text file.

Re:Anyone can program, yet again (2)

oiron (697563) | more than 3 years ago | (#35988406)

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


  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!

Re:Anyone can program, yet again (0)

Anonymous Coward | more than 3 years ago | (#35988872)


20 GOTO 10

Why did you want to print 0 repeatedly? HELLO being a variable and all.

Re:Anyone can program, yet again (2)

oiron (697563) | more than 3 years ago | (#35989160)

I did say first program...

Re:Anyone can program, yet again (1)

morgaen (1896818) | more than 3 years ago | (#35989478)

Did you manage to trace that IP address in the end?

Visual Programming is Bad for Open Source (2)

iluvcapra (782887) | more than 3 years ago | (#35987584)

I've done some work in visual languages, like Pure Data/Max mostly, and some things you notice:

  • It's very difficult to do tutorials because you have to do tons of screen grabs. There's no such thing as a visual one-liner.
  • Visual programming languages always have ambiguous representations for algorithms, and they have a way of hiding internals and leaky abstractions under their sleves in a way that guarantees the code works but it works silently and relies on features that aren't intuitive.
  • Visual programming languages are hard to diff and merge in a clean way.
  • There's a lot of complete programs for Max that you can download for free, and sometimes people will customize odds and ends of them, but almost no particular project has many contributors -- it's just too hard to coordinate work, abstract away implementations and divide work.

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.

Re:Visual Programming is Bad for Open Source (1)

ShakaUVM (157947) | more than 3 years ago | (#35987794)

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.

Yeah, that was the same problem I saw with it. I am going to run through the tutorials in TFS just to make sure that I wasn't missing something, but it seems far too limited to even write Checkers or something like that.

Experiences of a Non-Programmer with App Inventor (0)

Anonymous Coward | more than 3 years ago | (#35988140)

I'm a non-programmer (well, only a single first-year university intro course) who tried out App Inventor a while back in beta.

I can say that the visual aspect of the interface is a huge help in explaining how a piece of code works to a non-programmer. However, I quickly found that the whole thing becomes unwieldy and confusing very quickly as the various sockets nest on one another unless you use a lot of functions to keep the code limited to short snippets. More a limitation of the visual metaphor than anything else, but probably also the sign of an unexperienced programmer (i.e. me).

I was, however, able to make a very useful dialer app that appends an access number from Yak Long Distance (using a phone number for the city of the user's choice) to any phone number in the phone's address book. The result is an app that lets me call people for super cheap rates without needing to write down or remember their phone number. The app works well, and I use it almost every day.

1.) As much as I like my app, I can't share it with the world on the Android market. So my effort felt wasted in the end.
2.) The .apk file is over 2 megs, even though the program is quite simple. These bloated .apks produced by App Inventor consume valuable phone memory since you can't move an App inventor app to SD (unless the phone in question is rooted).
3.) App inventor is plagued with a dearth of modules, and the modules that do exist have tons of buggy features that return no values or wrong values.

All in all, App inventor is cool and can be very helpful in teaching basic logic to new programmers. It is not a serious development platform. It also has a long way to go before it will be truly able to live up to its potential.

Disclaimer: After intensively using the software to develop my app, I haven't touched App inventor now in over 6 months. I'm not sure to what extent these problems have been addressed, since Google has and continues to update App Inventor on a regular basis.

- Anonymous Coward - (A.K.A. a lurker who is too lazy to register)

Re:Experiences of a Non-Programmer with App Invent (1)

wd5gnr (1682238) | more than 3 years ago | (#35988874)

1) Yes you can. The DDJ articles have a link to a tool that will package them for market and has the two examples on the market. 2) Granted. 3) Granted.

Just started playing with AppInventor this week (3, Informative)

element-o.p. (939033) | more than 3 years ago | (#35988726)

I just start playing with AppInventor this week, and right off the'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 AppInventor, so I kind of suspect that most of the concerns about a flood of crapware hitting the Android market as a result of tools like AppInventor may often be fueld by elitist snobbery My BASIC and COBOL programs back in my early years were pretty terrible (GOTOs and no concept of what a subroutine was...shudder). I'd like to think that with experience, my skills have gotten considerably better, so honestly, I'm excited to see what the kids who start with AppInventor now will be doing in another 20 years.

Re:Just started playing with AppInventor this week (1)

oiron (697563) | more than 3 years ago | (#35989186)

Thanks, that's a very nice, balanced review... You've saved us all the trouble of writing one ourselves... Somebody please mod parent up?

My feeling is that it will go a long way in making programmable interfaces using touch screens and other (whatever they may be) graphical-input-only devices.

This is just the beginning, I suspect that this particular path may turn out to be better than people fear...

Re:Just started playing with AppInventor this week (2)

lucian1900 (1698922) | more than 2 years ago | (#35990410)

You might find it interesting/funny to know that App Inventor uses the Kawa scheme framework to actually run code. So it's not a coincidence at all that you're writing RPN (postfix), the visual editor is just a graphical representation for s-expressions.

Why not use Hypercard or Homestead? (0)

Anonymous Coward | more than 3 years ago | (#35988958)

OMG people are so stupid - this has been done again & again.

It's all about Me, Me, Me. (1)

Animats (122034) | more than 3 years ago | (#35989178)

The entire first page is someone blithering about themself. There may be some useful information on later pages.

Good tool to mock something up (0)

Anonymous Coward | more than 3 years ago | (#35989578)

I've played with it, I've mocked up an app using it. App was 4mb by the time i was done. Then I turned around and rewrote it in Java, and it ended up being only 96k compiled so mocking maybe, but it's really not efficient.

Suprised there's no mention of Scratch so far. (1)

RoverDaddy (869116) | more than 2 years ago | (#35990152)

I read the first blog post and immediately recalled my experience playing with Scratch []
Looks like almost the exact same approach. My short experience with Scratch suggested that interesting apps could indeed be written in the framework, but that the complexity of any 'real' app would soon become burdensome in such a visual programming environment.

Does Not Address 90% of Programming (2)

StormReaver (59959) | more than 2 years ago | (#35990178)

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.

Re:Does Not Address 90% of Programming (0)

Anonymous Coward | more than 2 years ago | (#35990488)

If you actually try App Inventor it isn't really a GUI builder. Well, the block editor isn't which is mainly what the original blog was about. You can have exactly one screen and you lay stuff out. If you need more than one screen (which the guy did) you have to do ugly tricks. Also centering things, for example, requires non-intuitive tricks. So it isn't a very GOOD GUI builder at any rate. But what I think they were saying was more the block editor. You either understand iteration or you don't. Showing me a purple block with some green blocks inside of it really doesn't help me do iteration. Like the thing said maybe if you could switch to a representation to see your flow and then switch back to text to write your code... especially can you imagine like SVN or CVS for something like this (shudder). Not that I disagree with you. You are right -- it is the abstract thinking people need. And the GUI is the easy part, especially just the implementation of a well-thought out GUI. But the question is: do pretty colors and snap together statements really make anything easier? Or is it just graphical for graphical's sake.

very informative. (1)

sgt scrub (869860) | more than 2 years ago | (#35990336)

i looked it up. cobol does indeed use english works.

AppInventor is useless (1)

t2t10 (1909766) | more than 2 years ago | (#35991156)

I'm sure someone can create a nice web-based, visual development tool for Android. AppInventor is not it; I found it to be cumbersome and useless.

Need to be able to export the blocks to XML (1)

Sangbin (743373) | more than 3 years ago | (#36003986)

Hiding the Java code from you is not a problem if you consider App Inventor blocks as a new programming language; it's not a translator therefore it doesn't need to show you an equivalent "generated code" that people claim it's missing.

However, as a new language, it's missing a big feature: googleability. In order to debug and ask questions, you need to be able to easily show a piece of code and let people search it through Google. This means that you need the code to be in text, not diagrams.

Adding a feature like, right click on a block -> export to XML, would be tremendously helpful to make this prime time.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?