præclarum

The home of Frank Krueger.
Jul 17 '14

Mocast

image

For the past couple months, I have been working on a top secret project that aims to redefine the way work will get done, address key industry mobility challenges and spark true mobile-led business change. I’m just kidding, it’s a podcast player!

Why?

Mocast is not going to redefine how work gets done, but I am hoping it redefines how you listen to podcasts.

I wrote Mocast because I was unhappy with the iOS podcast app selection. While there are almost as many iPhone podcast players as there are weather apps, I find that they all have two fatal flaws.

First, they take downloads way too seriously. Most UIs differentiate downloaded vs. not downloaded episodes and bifurcate their interface along those lines. This is silly to us podcastistas who aren’t the greatest at planning ahead.

Second, they take new episodes too seriously. Whole apps seem built with only new episodes in mind as they hide away the back catalog. I don’t know why this is. My favorite podcast, The Incomparable has an amazingly rich back catalog of episodes that I love to listen to. It’s nice when a new episode arrives but there’s no need over-emphasize them at the cost of the full catalog.

How?

First, and most importantly, downloads are completely optional when using Mocast. You can always play an episode immediately, whether you have downloaded it or not thanks to streaming.

Next, it’s a single-screen thumb-based UI. You see, I walk a lot in parks and can’t stand apps that have a complex navigation history with back buttons with crazy nesting - I need to be able to do everything with my thumb and I need the screen to be predictable. Mocast makes that possible. You will only ever see a list of episodes, a search box, and play controls. There is no Now Playing screen, no episode screens, just episodes and a big play button. I even tried to limit the number of buttons all together. This is a slide-happy, thumb loving app.

Mocast puts you in control with queues. Mocast presents four different lists of episodes: Per-podcast, New, Queued, and History. While Mocast manages most of those lists, The Queue is fully under your control. You can add episodes to listen to later or setup a nice set of old favorites to listen to when nothing new is coming in.

Mocast acknowledges and embraces our busy lives that prevent us from completing episodes. It keeps a running History of past played episodes (and of course where you left off) so that you can jump around between episodes without ever worrying about forgetting to finish one.

Lastly, and this is one of my favorite features, Mocast lets you perform offline full-text searches of all episodes’ show notes. Do you want to see all podcasts that mentioned WWDC 2014? Easy. How about all Star Wars episodes? Done. Every list Mocast shows is searchable and the search box is always ready for you at the top of the app.

A bit of fun

While I truly believe Mocast has a lot to offer in terms of usability, I think it’s a fun app too. Here are a few of my favorite features.

Siri is used to announce episodes. Yes, that Siri. It took some string pulling and I have to deal with a 150 page rider, but she’s there to let you know what you’re listening to.

The time scrubber is thumb friendly, velocity controlled, big and bold. I can’t stand apps with tiny scrubbers so I hope you will enjoy this one.

Dark disco theme that adapts to your episodes. Mocast is just a sad dark gray app until you start adding podcasts. But once they’re in, it lights up with their colors and keeps those colors moving around. It’s hard to describe in words, so I hope you’ll risk the $3 to see for yourself.

There are more features than this tucked away! I hope you’ll check them out!

Colophon

As with all my apps, I wrote Mocast in C# using Xamarin.iOS. She came out to be about 8,000 loc with about 60% of that code lying in the UI layer.

12 notes

Jul 11 '14

My Xamarin Studio F# Wishlist

I am writing a large iOS and OS X app in F# and am totally digging the honeymoon phase. Not only is F# a crazy powerful language, but it has a great interactive code executer built right into the IDE. In all, it’s a wonderful development experience.

(If you haven’t seen it, check out my hastily recorded Interactive F# Development in Xamarin Studio video.)

While F# in Xamarin Studio is great, it does lack a few features I miss from the C# experience. These include:

Sorted Intellisense. If you didn’t know, you can hold the Shift key while upping and downing through the Intellisense to switch to an inheritance sorted list of members. This is not only useful, but critical to exploring new objects and APIs. It also lets you filter out all the junk that comes with base classes (I’m looking at you NSObject). I miss this feature so, so much (imagine creepy Anakin Skywalker saying that).

Expand Selection using the AST. Another important but often missed feature of Xamarin Studio’s editor is the ability to expand your selection based on the language’s syntax tree. If you have the text “fo|o + bar”, then expand the selection, you get “[foo] + bar”. Expand again, and you get “[foo + bar]”. This is an amazing keyboard shortcut that services quick identifier selection, expression selection, method selection, and more.

Rename Refactoring. You know, you don’t think of it much, but when someone takes away your rename refactoring, you all of a sudden are back in the 1990’s coding in Turbo Pascal with your crappy IBM PS/2 debating whether code clarity is worth the trouble…

Thanks to Don Syme for setting me straight: Xamarin Studio supports Rename and it works great (even across projects). I’m going to meditate a bit on how it’s possible to be completely blind to a feature.

Search for Definition. MonoDevelop used to have a great tool for jumping to any definition in your code. Just hit Cmd + . and you get a great search window. Xamarin Studio screwed this up a bit by putting the window in your peripheral vision and limiting the results to just a few items with not enough info to distinguish them. But I digress. Even in its not-very-useful state, I still wish I could search for and jump to definitions in F# code more easily.

NUnit IDE Integration. Xamarin Studio has shortcut “test bubbles” in C# code when using NUnit. These bubbles are right in the editor with the code so it makes running and debugging tests a two click task. While F# of course supports NUnit testing, the editor doesn’t care. Too bad.

And then the crashing. Hey, it sucks to be on the frontier, software sometimes breaks and needs time to be refined. I just wish I could go more than 5 minutes without Intellisense crashing or more than 15 minutes without Xamarin Studio crashing. Coding F# with functioning Intellisense would be so groovy…

What’s the good news? The Xamarin Studio F# integration is open source! That means I should “put up or shut up”. I have a small amount of experience writing XS addins and a small amount of experience coding F# - I figure this qualifies me to at least send a pull request. Wish me luck!

2 notes

Jan 17 '14

Automated UI Testing with Cucumber and Calabash

There comes a day in every developer’s life when they have to admit that they just aren’t good testers. We don’t think to hit buttons in strange combinations, we test features in isolation, we don’t re-test for regressions, and we simply don’t do it often enough.

Thankfully most of us realize this early in our careers. We adopt unit tests to make sure our functions work (at least in isolation). We worship continuous integration servers. We annoy friends to test our apps and watch in horror as they hit submit buttons ten times in rapid succession. (A week later, you ask them to try again. “Ha! I won this round!” you gloat.)

If you’re lucky enough to work at a company with dedicated testers, you even get to substitute “colleague” for “friend”.

But what if your friends just aren’t cutting it? Or what if we cared about them enough to realize that clicking every button in the app on every release is just a new form of torture so far unidentified by the US government?

This article will introduce you to Gherkin a language for specifying tests, Cucumber the tool that runs those tests, and Calabash the library that interfaces Cucumber with the platform you’re testing. This article will use an iOS app (Calca) written with Xamarin.iOS as an example, but it is mostly platform agnostic.

It is my goal to show you that this environment is easy to setup, that it’s “not-so-hard” to script UIs, and that using this setup will make your apps more reliable. You will certainly relieve some of the burden placed on those you’ve roped into testing.

Automating the UI

We wish to automate testing the user interface of our applications. This will, inevitably, boil down to tapping on the screen, waiting for the app to respond, then validating that response.

We specify these steps using a language called Gherkin that codifies these phases of testing using natural language.

To demonstrate this natural language, here is a series of steps I use to automate document renaming in Calca using Gherkin:

Scenario: Renaming a document
  Given a new document
  When I touch the title
  Then I should see "Rename"

  When I enter "A New Name" into the "Rename" input field
    And I touch the "Done" button
  Then I should see "A New Name"
    And I delete the open document

Yes, this is a scripting language, and a pretty clever one too.

Steps are grouped into Scenarios which are like scripts but don’t have variables or branching. We can see that my scenario is called Renaming a document.

Each step is specified as a Given, a When, or a Then:

  • Given sets up the preconditions of the test
  • When specifies an action the user takes or acknowledges an event
  • Then validates the state of the app

And, Or, and But can also be used to make the steps more readable. (The truth is that all these labels are ignored by the test runners and are there simply to make your tests more readable. Use them.)

You will notice that my script is pretty self explanatory because it is written in a formalized English. I’m sure I could hand it to any non-programmer and they could comprehend it and even validate its correctness.

Imagine an entire app’s behavior described in the language of scenarios and steps. It would be a lot like a functional spec for the app. Perhaps we don’t want fall down the slipperly slope of overspecification, but there are certainly benefits to a written and always up to date description of an app’s behavior. For example, these steps are very close to being user documentation - perhaps we can have verifiable documentation too.

What if you wrote these scenarios before you wrote the app’s code? This is like Test Driven Development (TDD) where you write functional tests before writing the code that makes it pass. Since we are at a higher level of usage, this style is called Behavior Driven Development (BDD).

The BDD process goes something like:

  1. Imagine a new feature
  2. Document the feature as a set of user scenarios needed to exercise that feature
  3. Code and code until all the steps of #2 pass

Cucumber, the tool that will execute these scenarios, is designed to handle this workflow and is a pleasure to use. It even handles executing undefined steps gracefully going so far as to stub out the code needed to define them.

Predefined Steps

Calabash comes with a variety of predefined steps. These include:

When I touch "accLabel"
When I scroll down
Then I wait to see "text or label"
Then take picture

among many others.

Defining Steps

You will, eventually, want to write your own steps. You’ll do this for a variety of reasons:

  • A part of your UI is hard to distinguish with the predefined steps
  • You want to abstract out elements or interactions with the UI (for platform differences)
  • You want to reuse code between scenarios
  • You want to change the step dialect

Steps are defined in a Ruby DSL (yes, that Ruby) with a template sentance regular expression and a script body. The script body will be executed when the step is executed.

For example, the step And I touch the "Done" button is implemented with this Ruby DSL:

Then /^I (?:press|touch) the "([^\"]*)" button$/ do |name|
  touch("button marked:'#{name}'")
  sleep(STEP_PAUSE)
end

Notice the use of the regular expression that matches the step’s natural language. Also note that the regex has a grouping that is mapped to the name parameter of the body of the script. This makes writing parameterized steps easy.

This script itself makes use of the Calabash library to interface with iOS. The touch function queries the view hierarchy for a UIButton with an accessibilityLabel (marked) with the name specified in the step. In our case, it will look for a button with the label “Done”. The sleep function is run to throttle Cucumber - we have to give those animations time to finish after all.

To get a feel for step definitions, I recommend reading the reference to the standard steps provided by Calabash for iOS while simultaneously reading the source code to those steps.

You will find out that you need to learn two libraries in order to write step definitions:

With this knowledge you can leverage Calabash’s built in steps and your own custom steps to write descriptive and useful scenarios.

A Balancing Act

Let us look at the rename scenario and note where each step comes from:

  • Given a new document - App-specific
  • When I touch the title - App-specific
  • Then I should see “Rename” - Calabash
  • When I enter “A New Name” into the “Rename” input field - Calabash
  • And I touch the “Done” button - Calabash
  • Then I should see “A New Name” - Calabash
  • And I delete the open document - App-specific

Three of the steps were written by me, while the other 4 are predefined Calabash steps.

I have found there to be a balancing act between writing your own steps and using the predefined ones.

On one hand, the predefined steps are easy to write and are general enough to be useful.

Unfortunately, your scenarios can end up with a lot of duplicated code as features tend to get buried a few clicks away and usually involve some cleanup.

I defined the Given a new document step because I found myself repeatedly writing these Calabash steps to create a new document:

Given I touch "Add"
  And I touch the "New Calculation" button
  And I touch "Done"

These three lines of code got repeated in a lot of scenarios because I liked to test when there was a new document available.

Eventually, I wisened up. Instead of repeating these lines, I wrote a new app-specific step in Ruby:

Given /^a new document$/ do
  macro "I touch \"Add\""
  macro "I touch the \"New Calculation\" button"
  macro "I touch \"Done\""
end

I was able to take advantage of the macro function to write this custom step in terms of other steps.

Now I am able to write Given a new document in my scenarios instead of those three Calabash steps. It’s a win.

Custom defined steps can be useful to abstract parts of UI in order to smoorthly adapt as the application’s UI changes. That is, they can be used to decouple the test from the UI. However we must also be weary of our tests getting too abstracted from the UI. We might end up testing our own tests then.

Exploring Your App

Calabash relies on accessibility labels and classes to identify views in your application (see the query syntax reference). This is far more reliable than identifying views by location. It also means you have to take a bit of care when writing your apps to make sure all interesting views have good accessibility labels.

If your app is all buttons and text fields, everything will just work as you expect.

But chances are, your app is more complex than that. Fortunately Calabash comes with an excellent tool for exploring your application’s views and verifying that you’re setting accessibilty labels correctly.

Once you have installed everything, you will have a tool called calabash-ios console. This tool gives you an interactive Ruby session with the Calabash API ready to be accessed.

All you have to do is run your app (that is configured to talk to Calabash) in the iOS simulator, run this console, and then start typing queries.

For example, you might want to see all visible views:

query("view")

This will give a list of views, their classes, the screen positions, and the accessibility labels.

From here it’s just a matter of playing with your UI and discovering which queries identify the views you intend.

For example, I might look for a button with the label “Done”:

query("button marked:'Done'")

If, however, I didn’t use a UIButton, but instead implemented my own class, I might try a different query:

query("view:'MyApp.CoolButton' marked:'Done'")

This would find all the CoolButtons visible in your app (in the namespace MyApp) with the label “Done”.

To speed up exploration, there is a short-cut query called labels that just returns the views’ labels. For example, you can type:

labels(“button”)

to get a list of all the labels of all the UIButtons visible on the screen.

Fixing Labels

You will find that it is hard to find a query that uniquely identifies a view if it does not have a good label.

If your app uses custom UI elements or other fancy trickeries, chances are your accessibility labels are not nicely set.

As an additional incentive to having good labels, iOS makes use of these same labels to provide VoiceOver for guided screen access. Your app will be easier to use if you get all this right. For iOS, read the Crafting Useful Labels and Hints section of the Accessibility Programming Guide.

All views that implement the UIAccessibility Protocol have an accessibilityLabel property that can be easily set.

To set the label in Xamarin.iOS, you simply write:

playButton.AccessibilityLabel = "Play";

If you inherit from a class that does not already implement UIAccessibility, then you will need to export this property:

[Export("accessibilityLabel")]
public string AccessibilityLabel { get { return "Play"; } }

Getting Started

The remainder of this article gives an overview of what you need to start writing UI automation tests for your own app.

Install Calabash and Cucumber

Calabash documents the installation procedure in their README.

Roughly, you will use Ruby’s gem package manager to install Calabash and Cucumber on your system.

$ sudo gem install calabash-cucumber

Instrument Your Application

To interact with your app, Calabash uses an internal web server that your app must launch.

For Xamarin.iOS, this is rather easy to setup. Just reference the Calabash component from the Xamarin Component Store and add this line to your AppDelegate’s FinishedLaunching method:

#if DEBUG
Xamarin.Calabash.Start();
#endif

Calling the Start function is all you need to do.

You want to conditionally compile that call because Calabash uses evil tricks to get its job done. Apple will not let you release an app with that kind of trickery so you want to control its existence.

Personally, I recommend using another definition such as CALABASH_INSTRUMENTATION because you might actually want to test against release binaries. But DEBUG is what appears in all the docs.

Create Your Cucumber Features

The next step is to start writing scenarios. We begin by using a tool to scaffold all the files needed to run the scenarios. Invoke this command in your iOS project directory:

$ calabash-ios gen

This will create a subdirectory features with this hierarchy:

features/
  step_definitions/
    * Ruby step definitions (*.rb)
  support/
    * Don't touch anything in here
  * Gherkin feature definitions (*.feature)

What is a feature? It’s just a group of scenarios. For example, I might have this feature:

Feature: Rename
  ...
  Scenario: Renaming to a new name
    ...
  Scenario: Accidentally trying to rename over another doc
    ...
  Scenario: Renaming to the same name
    ...

These three scenarios are written in a single file called rename.feature that is stored in the features directory. All scenarios must be specified in a feature file.

Custom defined steps get placed in Ruby files in the step_definitions directory. I like to have 2 files there, one that is shared between all my apps, and one that contains steps specific to the app being tested.

For Calca, I have:

shared_steps.rb
calca_steps.rb

in features/step_definitions/.

Running Cucumber

Cucumber will run all the features and all their scenarios when executed.

$ cucumber

It detects which app to execute based on the current directory (which should be your project directory, not the features directory) and runs the version already installed on the Simulator.

It will execute each scenario as a separate invocation of your app on the simulator. That is, your app will be closed between each scenario and brought back up.

Cucumber has a nice display (for a console app) so make sure your terminal has ANSI colors enabled and is nice and wide.

You can control the simulator parameters by setting environment variables before executing cucumber.

$ SDK_VERSION=6.0 DEVICE=ipad cucumber

You can also run specific features by passing them as arguments to Cucumber.

$ cucumber features/rename.feature

Running on devices is also supported.

Conclusion

I worry a lot when I release an app. Did I test it thoroughly, did I hit every button like a monkey? I will freeze code and just test for days leading up to a release. It’s a very stressful time; every little bug fix can accidentally break something else.

And so, every small fix leads to a full end-to-end testing of the app. But the truth is, that’s impossible to achieve. Inevitably a mistake gets through, a regression introduced at “some point”.

Calabash, Cucumber, and Gherkin relieve the stress of regressions. If I simply take the time to write a feature that excercises new code through a few scenarios, then I can worry a lot less about introducing regressions.

I can run the full test suite any time. I can run it on a variety of devices. I can compare different versions of the app running on different operating systems. I can wire it into my continuous integration server and always know the state of my apps even as platforms evolve. Bye bye bitrot.

Finally, I can stop bothering my friends. I can free them from the mundane testing to do what they do best - breaking my apps in new and inspiring ways (and I can code those into scenarios later).

4 notes

Dec 29 '13

Microsoft’s New Systems Language

As a programming language nerd I had mixed feelings when Jon Galloway tweeted about Microsoft’s new programming language.

"Why are your feelings mixed?" I kept asking myself. I love new programming languages. I took an internship at Microsoft just so I could be closer to the people who made C#. I read language specs for fun. I write compilers for fun. I sell a programming language, interpreter, and IDE. I used to read every post on Lambda the Ultimate. I check Jonathan Edward’s site daily to be inspired - with the hope that he will share more wisdom with the rest of us.

So why am I not thrilled? Finally, after as much soul searching as 4 hours of sleep allowed me, I identified a few reasons for this pit in my stomach:

  • A systems language? In a world of apps that compete almost solely on usability, who cares about a systems language? We’re not writing OS’s. We’re not writing databases. We’re writing apps for humans on the go - new languages should make that easier. The language’s design should be based on improving consumer apps not making life easier for Intel.
  • Next generation languages have to work without an explicit compile step. JavaScript has shown us how productive you can be if you get the compiler out of the way (just hit Cmd + R). Smalltalk showed us how to push that to the extreme by merging development with execution. This language doesn’t have any of that, and the closer a language/runtime is to the hardware, the harder this is to pull off.
  • Microsoft has PL ADD. Every year Microsoft’s evangelists are tasked with promoting a new programming language. The Windows team, ever haters of good things, decided that JavaScript was the way to write Windows apps, so we were all inundated with JS. Then they gave us TypeScript because they realized it’s hard to write big apps in JS. Then, and I really don’t understand this, they promoted new C++! This had all the old baggage and bad decisions of C++ mixed with new crazy syntax that only boost and Microsoft developers understood. We had to sit through more than a year of being told to use this mess (oh I hope no one listened). And now they are timidly announcing this language. I couldn’t help but to regard this as some kid showing me his newest Minecraft house. That’s cute darling, now leave me alone.
  • Microsoft is losing the consumer market. Just as Microsoft once rallied behind Security, I want to see the whole company rally behind User Experience. But they’re not. They just spent 4 years working on a systems programming language. Makes you want to smash your head against your desk until you can see their logic (please let me know if this works).
  • Joe Duffy is freaking brilliant. I had the opportunity to work just a couple doors down from Mr. Duffy when I would moonlight at MS. I heard rumors he was working on something secret for the last few years and have been excitedly waiting for an announcement. To find that MS had him holed up working on a systems language was… depressing.

It was this last point that I decided to tweet about:

You see, I made the classic mistake of fitting many ideas into a single tweet. (Lesson learned: if you want to make a point, one idea per tweet.)

I meant to just say I hate watching talent wasted. As an entrepreneur and technologist I know just how valuable smart programmers are. It is with a tremendous amount of jealousy that I look upon Microsoft with their vast richness of Human Resources. “What I could do with just 2 Microsoft developers…” I muse to myself. “I could create empires.” Point a smart person at a real problem and magic happens.

But of course, I had to push the tweet to include my other ideas: Microsoft needs to stop mixing PL messages, we have lots of good languages, the platform is strong, Microsoft isn’t doing what I think is best for them (take your medicine dammit!).

The tweet made sense to me, but in retrospect, just diluted all my arguments. You can guess the reaction!

Yeah, I agree: research is good and healthy. Microsoft has a massive and impressive research division. Every so often, the product guys even pay attention to it!

Christian gave the strongest argument against my view: Microsoft is, and always has been, a programming language company. I shouldn’t get upset at them for this. Progress is progress, I suppose, even if I feel it’s in the wrong direction!

We had a good time on Twitter yesterday discussing this. Everyone had good thoughts and we kept it civil. It’s hard to have a reasoned discussion on Twitter so I wanted to thank you all for your perspectives!

5 notes

Nov 6 '13

Audio Tales - Something a Little Different

One morning, I walked into a random presentation at WWDC. I didn’t know what it was about, but I was on autopilot and determined not to miss one session. It turned out to be Accessibility - not something I tend to think about as evidenced by my apps - but what else is a conference for but to break your habits?

Great information was presented, but one announcement jumped out at me and made my heart skip a beat: developers could now access the voice synthesizer. Even though iOS has been capable of synthesis and dictation for years, Apple has refused developers access to these features. Until now. Siri, we promise to be kind.

This was the iOS 7 WWDC and everyone’s minds were filled with hairlines, supersaturating blurs, and bouncing - all sorts of bouncing. I too wanted to make a pretty iOS 7 app and set to work on my weekend app. A weekend turned into 5 months (thanks Calca!) but I am happy to announce that I finished it:

Audio Tales: The eBook Reader

The app takes ePubs and turns them into audio books using iOS’s various voices.

It highlights words as they’re spoken so you can follow along or day dream a bit without getting lost.

You have the familiar controls of Play/Pause, skip forward and back a paragraph, scrubbing through time, and jumping to chapters.

It is fully background audio compliant so you can control it from your headphones or car stereo.

You can control the reading speed from 50 words per minute up to a breathtaking 600 wpm.

You can even control the region that narrator is from. Do you prefer your books read to you in an Irish accent? Or how about a German?

And it’s pink.

Audio Tales has been a pet project of mine for so long now. I’ve listened to Alice’s Adventures in Wonderland so many times that the stupid Queen still haunts my dreams. But, none the less, I’m really thrilled that it’s available to everyone now.

1 note

Nov 1 '13

Calca 1.2 - Experiments in Text Editing

Let’s face it, text editing text on iOS isn’t the most enjoyable exercise. Text input is fine and dandy, I love flinging my thumbs or resting the iPad on my lap. But editing, no sir. That just sucks.

I’m talking about moving the cursor to make a correction, or moving it to change a block of text, or selecting a block of text. None of that is easy. Version after version of iOS has the same text editing features, so Apple doesn’t know how to make it any easier either.

In July, I released Calca - a text editor based calculator that came from the desktop world. In the desktop world modifier keys, cursor keys, and crazy key mappings make editing fast. There are even whole religions devoted to key mappings.

But we have none of that on iOS. On iOS, you get an uncontrollable keyboard and the ability to give it an ugly appendix. Calca takes advantage of this and makes a helpful appendix with common symbols and auto completion options.

image

The appendix (technically a “keyboard accessory”) does a lot to help input, does nothing for editing. You were still stuck with slow cursor movement and tricky block selection.

I wanted to make editing easier and ended up implementing three small features that, I think, accomplish that.

Tapping a Number Selects It

image

When you tap an arbitrary location while editing, the cursor will jump to the beginning or end of a nearby word. This is almost always what you want to happen.

But when it come to numbers, you often want to replace it outright. This means that you have to do some fancy backspacing or block selection.

To make selection easier, Calca will select the whole number when it is tapped. This makes typing in new values very easy and will be useful for the third gesture.

Swiping Left and Right Move the Cursor

image

Fine cursor movement is normally achieved by tapping, holding, and waiting (forever) for the magnifying glass to appear.

To make precision cursor movement easier, Calca responds to horizontal swipes and pans. When you pan your finger, the cursor moves at about the same rate giving the impression that you’re nudging it along.

I got the idea for this while playing with Editorial by omz:software. Editorial has a similar feature but is limited to only working on the keyboard accessory and is a bit slow.

Calca allows the gesture in the editor and the keyboard accessory giving you plenty of room to control it. It was also sped up so that the cursor speed matches your finger speed. I found this necessary to making it feel like you are really in control.

Swiping Left and Right to Modify Numbers

image

Editing a number usually involves typing in a new value using the keyboard. Thanks to the number selection gesture, this is now very easy.

But typing presents a distraction when using Calca - part of the fun is watching calculations update when you change values. But if you’re staring at the keyboard then you’ll miss the action.

Now, when you swipe left and right, the number is incremented and decremented. This free’s your eyes to explore the rest if the document and is a great relief from pecking keys on the keyboard.

This mode is only active when a number is selected so it works very well as a follow up to the first tap gesture to select numbers.

Thank you for reading! I hope you’ll give Calca 1.2 on iOS a try!

3 notes

Oct 30 '13

Buttons Considered Harmful

I realized that my favorite apps on the iPhone are the ones that minimize the number of buttons in their UI.

I’m learning that these little rectangles that only understand tap gestures are real nuisances. I watched my mother poke at one over and over completely failing at this simple gesture. Why? Well she wasn’t the greatest aimer (still getting used to the screen, and we do love to put buttons all over the place at the minimum recommended size) and she also couldn’t help but to wiggle a little on contact - Apple’s tap recognition tuning was just a bit too tight for her.

So it got me to thinking about how these little vestiges of the mouse era just aren’t sufficient in the era of pocket devices used while walking down a busy street eating a hotdog.

It got me thinking about my favorite app, Clear - the todo list app from Realmac Software. Clear uses gestures to add items to a list, sort the list, check off and delete items, and just about everything else. It’s easy to think of an app that would map a button to each of these actions (Mail.app?) but Clear is a completely different kind of app because they didn’t.

It’s a joy to use. It tolerates sloppy thumbs and accidents. It re-enforces gestures with visual and audio cues. And when it does need you to tap (a gesture they reserve for renames only) then the hit target is as wide as the screen. It’s a glance-able UI - once I’ve seen it, my fingers can do the rest.

This is the opposite of buttons where you have to concentrate to tap them. I even started teaching my mother different device grips to increase stability while moving to hit a target. At that time, I wished every app had Clear’s UI.

As an app developer, I’m trying some new ideas - really, finally, thinking about gestures and how they can be used (and how not to misuse them). I challenge myself now to think of a UIs without buttons. What do they look like?

3 notes

Oct 21 '13

Calca for Windows, you asked for it!

image

Calca for Windows has been the #1 asked for “feature” since Calca for iOS debuted in July. Today, I’m happy to announce that it’s finally available for purchase! For just $9.99 you can own this powerhouse of a calculator.

A very Windows app

Calca for Windows was designed to be fast and light weight. It ships as a single executable that doesn’t need to be installed (don’t worry, there’s an installer too if you want it) and presents a minimalist user interface. There is no drama of loading a big IDE or massive spreadsheets. Calca pops right up and begs you for something to do.

And, oh, it works on Windows XP. Yep, that’s right: Calca was designed to work where you have to work, no judgements.

If you’re just getting started with Calca, make sure you read the Introduction and Examples under the Help menu to get started.

A more powerful engine

One of the most exciting things about this release is that it ships with version 1.2 of the Calca engine. In addition to numerous bug fixes, this version also has fantastic units and currency support.

You can easily convert simple values:

12 tbsp in cups => 0.75 cups

Units have been implemented in a very general manner allowing you to do some pretty advanced computations.

Here is one of my favorites: how to calculate how much water falls on your land throughout the year.

land area = 0.25 acre

avg annual precip = 36.15 inch / year

daily rain accumulation

     = avg annual precip * land area in gallon/day

     => 671.9012 gallon/day

In order to perform this calculation, Calca had to know how to convert between acres, inches, days, years, and gallons and it does it all with a minimal amount of typing.

There are lots of other improvements, but since this is a new release, I won’t bore you all with details here. But watch this blog as I will be pointing out nice new features from time to time.

(And don’t worry Mac and iOS friends, updates are being submitted to Apple this week so that you will get these new features too.)

Code reuse numbers

For my developer friends out there who like to keep tabs on me, I was able to reuse 18,000 lines of code from the previous Calca versions and only had to write 3,000. The majority of that code is implementing a document-based application architecture.

Here the code reuse stats in picture form:

image

86% code reuse is great, though I do with it was in the 90s. The Mac is able to achieve this because of the powerful Cocoa library that has first-class support for document based applications. On Windows, I used Win Forms and had to implement all the file management by hand just like with iOS. Speaking of iOS, it’s numbers have grown a bit because I have some nice surprises in store for its updates.

6 notes

Jul 16 '13

4 notes (via jakemarsh)

Jul 15 '13

Calca OS X Now Available & Code Reuse

Calca is my latest app - a text editor and computer algebra system happily married together. The reaction to Calca has been overwhelmingly positive. I am very excited that people are finding it useful. Make sure to leave reviews and tell your friends. :-)

Anyway, I’m please to announce today that the OS X version of Calca is available. In this form, Calca really shines. It’s the same powerful engine as before, but it’s much easier to manipulate text documents on Mac and it can handle much larger documents.

I was even able to put in some convenience features from IDEs: matching parenthesis highlighting, matching identifier highlighting, and indent and commenting keys. The app is also iCloud enabled so all your Calca for iOS work is available. I hope you enjoy it!

Following the tradition of iCircuit, I want to take a few minutes to report how much code reuse I was able to attain between the iOS version and the Mac version. To do so, I simply ran the Code Share Measurement Script. It produced the following raw data:

app    t	u	s	u%	s%
Mac	12253	916	11337	7.48 %	92.52 %
iOS	14227	2890	11337	20.31 %	79.69 %

We can see that Calca’s engine - the shared code - is 11,337 lines of code. One could say it’s an elite engine.

Here is a picture showing that same data. The code in green is shared, while the code in red had to be written specifically for that platform.

image

This is showing that the UI code of the iOS version is nearly 3,000 lines of code compared to 1,000 lines for the Mac version. The iOS version’s UI is 3 times as big as the Mac’s.

Why is the iOS code so much bigger than the Mac’s? One answer: file management.

iOS human interface guidelines ask developers to minimize the use of the file system in normal interactions with our apps. To that end, there are no UI controls specifically designed for file management. There are no directory browsers, no file open or save dialog boxes, no UI to simply rename files. All of this has to be coded per application by the developer.

On iOS, Apple stands over your shoulder commenting “look how much effort it takes to write a document based application, are you sure you want to do it this way?”

On OS X, Apple wants you to make document based applications and gives you a fully working one with essentially no code. Honestly, I’m surprised that it took 916 lines of code to write the Mac UI - the UI is very simple with all the smarts hidden behind a text editor. There are a lot of “tricks” in that code to make the editing experience pleasant - most of which involves tricking the text editor into behaving itself.

This is the general lesson I’ve learned over the years: writing iOS apps is a hell of a lot more work than writing Mac apps. Enlightening? No. Honest? Yeah.

I wrote this app, as I do all my apps, using C# and Xamarin tools. I want to take a moment to thank them for their awesome product. Calca was a labor of love and it was wonderful to use my favorite tools to create it.

4 notes