30 October 2013

iTunes 11 modal alert dialog overflow

Do you tend to show modal dialogs to show issues to the user when processing his data? Well, think twice, or you might end up upsetting your users like Apple manages with iTunes 11.

See here for a screen recording I created when trying to update my iOS apps after about a week from the last update.

Blogger was supposed to show a video box here,
but that doesn't seem to work.

Admittedly I am suffering from iTunes 11 more than most users because I have two iTunes accounts: A German and a U.S. account. And I have downloaded iOS apps from both accounts. This leads to iTunes wanting to update all apps for both accounts at the same time, even if it only shows me the German updates.

However, before iTunes 11, this was still manageable. iTunes 11 made this much worse.

Also, there are other alerts in there that even the usual Apple customers with just one iTunes account might experience, such as the late-appearing "age restriction" notice that pauses downloading, and messages about problems with particular apps without naming those apps.

Overall, iTunes 11 does this all plain terribly. Apple used to excel at good user interfaces. Nowadays, I get the impression they take the kids right from college, let them work on these programs with no supervision from anyone who still has a clue about how to avoid such bad user experiences.

(I've also reported this to Apple via their bugreporter, see http://www.openradar.me/15350892)

11 October 2013

Understanding the Xojo (REALbasic) language

This is a small assortment of tips and tricks to make you understand the Xojo language better.

The differences between identifiers, keywords and reserved words

Even though the IDE paints them all the same color, they're not the same in the way you can use them in code code:
  • Identifiers are words you can use to name your methods, properties, variables etc.
  • Reserved Words (or reserved names) are all those that you can never use as identifiers. This includes: if, then, to, function, end, attribute
  • Keywords are a mix of the above. They are all those words that are pre-defined by the compiler. This not only includes the Reserved Words but also standard types such as String, Integer, Boolean and Color. But it does not include Date, for instance - that's a name from the framework, i.e. it's practically code written in Xojo that you do not see but that the compiler secretly adds to your source code when building your program. You can tell the difference if you use XojoScript (RbScript), which is a bare bones access to the compiler without most of the framework: While you can use Color there, the Date class is not available. (Note, however, that even XojoScript gives you a small framework to work with that includes some strings operations and the Print function, for instance).
Now, here's the interesting part:

Whereas you cannot declare a variable with the name attribute, you can declare one with the name boolean!

Here is an example that actually works:
  dim boolean as integer
  boolean = 2
  MsgBox "The value of the variable 'boolean' is "+Str(boolean)
While the above is quite some nonsense, it can be used in other ways, too, for instance in an enumeration. You can declare an Enum named Types and add the values String, Integer, Boolean to it. Then you can write:
  dim t as Types
  t = Types.Integer
BTW, for that very reason that reserved words (if, then etc.) are not the same as predefined types (String, Integer etc.), I tend to write the former always in lower case while I write types (both predefined and self-declared ones) always in upper case. So, while some may think my mixed case code writing is inconsistent, it actually follows rules based on the understanding of the language.

Boolean logic

I often see beginners not making best use of Boolean types.

For instance:
  if found = True then
could also be written as:
  if (not (found <> true)) <> false then
The second example is clearly unreadable and therefore quite counterproductive. The first one is, to some lesser extent, similar in that nature.

The recommended variant would be:
  if found then
Read it aloud. Doesn't that sound better than the first example?

In the same way,
  if found = False then
should be written as:
  if not found then
Think about this the next time when you choose a name for a Boolean property or variable. Name it so that it reads well in a "if ... then" sentence, avoiding "= false" and "= true" constructs. It clutters your code and makes it often less readable.

Similarly, you may want to avoid constructs like these:
  if me.Value = true then
    button1.Enabled = true
    button1.Enabled = false
Why not simply:
  // enable button1 only if this checkbox is checked
  button1.Enabled = me.Value
Though, some may argue that "me.Value" is not self-explanatory, thus "me.Value = true" is adding some context. Here's an alternative that's even more self-explanatory:
  dim checked as Boolean = me.Value
  if checked then
and, analogously:
  dim checkboxChecked as Boolean = me.Value
  button1.Enabled = checkboxChecked