Category: tips

Web design is constantly evolving. Each year, new features are introduced to HTML, CSS and JavaScript. New page design trends emerge along with new style guides. AppStudio 6 has a number of changes to bring AppStudio development up to date with current best practices.

Responsive Web Design allows your apps to change how they display depending on screen size. Most new web development is based on RWD. AppStudio 6 has enhancements to better use RWD.

The position property, in Form Properties, is key to this. Its setting determines how controls are positioned on a form.

There are three useful settings: absolute, static and relative. (fixed is included for completeness, but not currently used by AppStudio).

Let’s discuss the differences and advantages of each.

Continue reading “Positioning Controls”

AppStudio 6 brings a new Header control. It’s a Common control, which means it will work with all frameworks.

Header puts a simple header bar at the top of your app:

You can customize the colors, font and size. It’s a simple useful control if used for just this.

What makes it special is that it can be used as a container for other controls. Add a couple of Buttons named Left and Right to a project with a Header. Now, drag them onto the Header:

Now it looks like this:

Change margin-all for both buttons to 3, and change the style of the Right button from float:left; to float:right;

Here is our final Header with buttons:

Of course, controls other than buttons can be used to create interesting headers.

In Version 6, we’ve changed a couple of error messages. One you saw too often, and the other you never saw at all. Both these changes will make you more productive.

New Version Warning

How many times have you seen this message when testing an AppStudio 5 app?

It warns you that you are about to overwrite the current version of your app. There isn’t any need to get this message every time your change your app when you’re developing. In AppStudio 6, there is a new setting in Project Properties called ‘newVersionWarning’. If set to false (the default!), this message will not show.

When your app goes into production, you might want your user to be warned if a new version is available, and give them the choice not to update. In that case, change ‘newVersionWarning’ to true and it will work just as it did in AppStudio 5.

Stop on Error

In AppStudio 5, the only way to find out if your app had a runtime error was to open the Chrome Debugger and look at the console. In AppStudio 6, errors are reported in a message box which appears over your app:

It will tell you the filename of the error (code.js), the line number and even the position in the line.

This catches most runtime errors. It doesn’t catch syntax errors, where the code is not properly formed. You’ll still need to use the Chrome Debugger for that. With this feature, I’ve found errors in code which I thought was working properly – it’s very handy.

You can turn off this feature in Project Properties by setting ‘stopOnError’ to False.

AppStudio 6 features an improved way of writing out your files when they are deployed.

Earlier versions of AppStudio tried to minimize the number of output files. The idea was that it would be quicker to load one large file than a number of smaller files which added up to the same size. This made debugging harder, since all the parts of your app were merged together.

Modern browsers do a great job of caching. Any file you have loaded recently (and maybe not so recently) is saved in the browser’s internal memory, so apps can load more quickly. A great example is jquery.js: since almost every web page uses it, it hardly ever needs to loaded. If your app uses caching (it’s on by default), all your files are automatically cached. That takes away the speed advantage of one large file.

An AppStudio app has two parts: the code which AppStudio generates, with all the forms and other boilerplate; and your own code (whether it is written in JavaScript, or BASIC converted to JavaScript.)

In AppStudio 6, the generated HTML, CSS and boilerplate code all go into index.html. All your code goes into code.js. External code files are put into .js files of their own.

It makes your app much easier to debug. When an error comes up, you’ll see just your actual code. You won’t have to dig through screenfuls of HTML, CSS and other stuff you didn’t write.

Chances are, your app will reload faster too.

There are a few options for reading bar codes: for web apps, for Phonegap apps and using an external scanner. Let’s look at each one and see what works.
Continue reading “How to read barcodes”