A Custom Textarea for Finicky in HTML5

I’m doing more work on bringing Finicky to HTML. Another interface that I wanted to reproduce was a custom input for note fields. It’s basically a hand-drawn top and bottom to user editable notes with a hand writing font. As you fill the notes, the area expands and the bottom moves with the expansion. It’s another cool UI tweak that my designer came up with that I want to honor in this version.

My first pass at it tried to use border images to fill the images as border-top and border-bottom on a textarea. I had one giant problem with that: CSS Border images are very unsupported. I couldn’t get them to work on Chrome, and they don’t appear to be accessible on a lot of browsers yet including the mobile browsers I am targeting.

My next pass was using a textarea. I got a little further along, but textareas are static. They don’t expand to fit the content. In fact, that’s sort of the opposite of their intent. They are supposed to stay static to accommodate large amounts of content. I’m sure I could do something with JavaScript to make that happen, but I hate doing that. No rational reason for that. I just feel that every time I use JavaScript to handle a display/style issue, I die a little on the inside. If I can do it in CSS, so be it.

My next attempt used the new HTML5 attribute “contenteditable.” Contenteditable basically says that the content in a given element is editable by the user. This means that I can just create a div that is user editable. The div has the added benefit of being able to dynamically resize itself when new content comes in. This is exactly what I am looking for.

It works perfectly until I actually go to use it in my mobile app. Surprise, surprise, contenteditable isn’t supported on Android yet.

So it’s back to textarea and JavaScript manipulation. (And a little piece of me dies.) There is a jQuery plugin that will make a text area expand with more content, but it seemed a little heavy since I’m not using jQuery in this application. The basic method is pretty straightforward:

  • Create a placeholder for a mirror of the textarea content
  • Create a function for onkeyup for the textarea that:
    • Sets the mirror content to be the content of the textarea
    • Grabs the height of the mirror
    • Sets the textarea height to that height

http://snipplr.com/js/embed.js
http://snipplr.com/json/62437

http://snipplr.com/js/embed.js
http://snipplr.com/json/62438

The basic solution is spelled out in this post on the textArea jQuery Plugin.

I went one step further and created a CSS transition that smooths out the height change of the textarea.

http://snipplr.com/js/embed.js
http://snipplr.com/json/62439

That’s a long road to getting it done, but it works. Here’s a working demo of it.

Circular Button with Photo Mask Using CSS

I’m currently working on porting Finicky over to HTML5 as a training exercise for building real applications (as opposed to more demoware) with HTML5 for mobile. It’s going fairly well, but there was one piece of UI that I was really worried about. It was a little complicated to render in ActionScript, and I feared it might be impossible in HTML. In fact it’s one of the few things I found much easier.

On the edit page there is a button for prompting you to take a picture of an item that you want to save. When you haven’t taken a picture, you see a little camera icon on the button. When you have already selected an image, you see a circular mask of the picture inside a circular frame created by the button. Look at the picture; it’s a lot easier to show than to explain. My designer really did a cool job there on that piece of UI, and I wanted to replicate it.

My first instinct should have been to look up “css mask” as it would probably be the easiest way if it was implemented. I didn’t. I instead went with using border radius to shape my button into a perfect circle and positioning it on top of the original button. In reviewing information on CSS Masking, I don’t think it would be the perfect solution. The images that I’ll be using in my final product are going to come from source images of different sizes. My method allows me to drop in any size/proportioned image into the background-image CSS property of my link and have it still work as a perfect circle. However, my research there makes me want to explore CSS masks more.

Anyway, back to the main point, how did I accomplish this?

First, I make an a link that I’ll use an a as the interactive part of the UI, as well as the holder for my picture. And I’ll wrap it in a div that will hold the button graphics.

http://snipplr.com/js/embed.js
http://snipplr.com/json/62377

I give the containing div a background-image containing the button graphic and I hard set the size to match the image size.

http://snipplr.com/js/embed.js
http://snipplr.com/json/62378

Once the container is done, I turn the a link into a circle by giving it a border radius of 50% of the height and width of the element. (I also used a background-color to see where I was putting it. )

http://snipplr.com/js/embed.js
http://snipplr.com/json/62379

Then I set the positioning to relative, to offset it within the containing div. I then fiddled with the top and left until the circle link was pretty equidistant from all sides of the containing div. It wasn’t just straight math because the drop shadow in the graphic made the blue circle of the button not completely in the center of the png file.

Finally I made a class with the picture I wanted to place in the background-image of the button.

Couple things to note here:

  • I hard coded the CSS for demonstration purposes, in my app, I’ll just add the background-image dynamically via the DOM.
  • This, like all awesome things, won’t work in versions of IE earlier than 9.
  • However, it has much more support than using masks, so I think it also wins on that account.

Here’s a demo with the full source.

Finicky, now for iPhone

I released a version of Finicky for iPhone earlier this week. It’s up and running in the app store.

Design Differences
You’ll notice that it looks somewhat difference from the Android version. This is by choice. In trying to get the iOS version working, I noticed significant issues with the UI we had designed and the iOS version. However I was still able to capture the feeling I wanted through color and font, without having to compromise too much on the design.

Feature Differences
I was able to support pretty much all of the features on both devices with the exception of mapping. I had issues getting the maps to work in production build. Worked fine in both the desktop debugging version of AIR and the fast compile version of the iOS app. It only failed on the full compile version of the iOS version. I anticipate having them working in an upcoming version.

Coding Differences
My original path was to have 2 separate code bases. I know, I know, this is all about not having to do it twice, but I was weak. The major reason behind this was that the iOS version had to run leaner, because, well, you know, performance is king. There was a good amount of Android specific UI and features that I just set to visible = false. That did terrible things for speed. So I stripped out all Android specific code, removed anything from the UI that I wasn’t showing on iOS, and generally improved performance.
However, after awhile I found two code bases presented a lot of problems. See, I’m not the best coder. I know, shocking. But I had bugs in my code. And I found a lot as I was going through and tweaking for iOS. But I had to manually copy them back to the Android project, as my git-fu is not so great.
I went back to one code base, but instead of ripping out Android specific UI and features, I loaded them conditionally. This gave me comparable performance, but allowed me to run both apps from the same code base.

2 Targets 1 Code base
If I had to do it again, what would I do different? First, off, due to some advice, I made a couple of good calls early. Kevin Hoyt pointed out, and Renaun Erikson echoed: design for iPhone 4 first, in terms of design assets. Everything else is a step down in terms of resolution. However, I developed for Android first. I’m not sure if this is the right move. I think it’s easier to add things, then it is too take them away. My process had me taking a whole bunch of things away. If I had it to do over I might develop for IOS first, then selectively add features for Android, BUT release for Android first. Maybe… I dunno. The thing I love about releasing on Android first is that I get stupid bugs out of the way on a platform that allows me to iterate through releases as fast as I can fix bugs. This isn’t necessarily a shot at iOS or Amazon or Nook or BlackBerry. I think their approval system does make you think harder about whether or not you have bugs before you submit. But, that being said my problem is not that I do not think, but rather that I often don’t think the right way. Being able to quickly react to real issues, is better then having me ruminate on what I think might be happening.

So there you have it. One app two platforms. Will be getting it onto Amazon and Nook next.

Getting the Distance Between Two Points Using ActionScript

As you may know I recently released an application named Finicky that allows you to match up locally available items to locations. These locations are stored by their latitude and longitude coordinates. One of the features I wanted to enable was a display of the distance between your current location and the location of each item. To do this you have to do some math on the two pairs of latitude and longitude.

This is evidently a common need, and there is a mathematic formula with a name and everything:

The haversine formula:

a = sin²(^lat/2) + cos(lat1).cos(lat2).sin²(^long/2)

c = 2.atan2(sqrt(a), sqrt(1-a))

d = R.c

This frankly sounds like some sort of experimental drink that pulls a Jekyll and Hyde on you, but instead of making you a monster, makes you upperclass British. But I digress.

One of the cool things about it, is that as written it’s capable of finding distance in whatever measurement you want, as long as you know the radius if the earth in that measure. Very cool, math nerdy stuff. 

There is a great bit explaining this, and a version of the haversine formula in JavaScript at Movable Type Scripts. But I had trouble finding an ActionScript version. So I just translated the JavaScript version. It is included below.


https://gist.github.com/1188832.js?file=example.as

Articles That Helped Me Build Finicky

On Friday I announced the release of Finicky, a new mobile app built using Flex and AIR. I wanted to take the time today to give some link love to all of the articles I used to work out the various challenges of writing a Flex Mobile application. Hopefully this list points people to something that could help them. I’m sure I’m missing some, as I did try to grab these links as I went; I’m sure I forgot to grab one or two.

Jason’s Flex Blog
I don’t know what exactly I cribbed from Adobe’s Jason San Jose, but I know it was a lot. Pretty much every bug patch, or skinning hint that I got was from him. Just read his whole blog.

@renaun posts: Using Flash CS5 to embed Fonts in SWC to use with Flex Hero and Flex Mobile Hero
Finicky uses a lot of custom fonts. My teammate Renaun Erickson has a great post here on getting all of your fonts packaged together in a SWC file for inclusion in your apps.

URI Handlers in AIR for Android: Phone Calls, Email, Text Messages, Maps, Market, and URLs « Christian Cantrell
I wanted to launch Google Maps for getting directions to a location listed in Finicky. Adobe’s Christian Cantrell sums up how to do it pretty perfectly.

Using Menus in your Flex 4.5 Mobile Application | Devgirl’s Weblog
Fellow Adobe Evangelist Holly Schinsky has a great post about using and styling menu controls in your Android AIR apps.

Reskinning the Android contextual menu (ViewMenu and ViewMenuItems) in Flex / AIR mobile to look like Gingerbread black – daaain’s thought stream
Daniel Demmel has another helpful article that helped me get through skinning the menus.

Android, AIR and the Camera | RIAgora
A small part of the UI is grabbing pictures that you can associate with items. To do this I needed to work with the camera in AIR. Another of my Evangelist peers, Michaël Chaize, has a helpful post about doing just that.

Tips for Flex mobile apps | RIAgora
Michaël also has a great article here detailing a bunch of little hints for building mobile apps with Flex. I used at least half of them.

ArrayCollection Filter Example | Flex-Blog.com
I’ll admit it, there are pieces of basic Flex that I don’t know off the top of my head. Filtering the results of an Array Collection is one of them. So Roelof Albers’ post was very helpful .

Tombstoning in AIR-Mobile Applications « Filthy Rich Applications
One of the things you need to do with mobile applications is deal with deactivation events, or what do you do when someone calls, or the user just switches to another application. Finicky uses geolocation, so I need to be very careful about preventing wasted battery life. Adobe Technical Writer, Frank Jennings’ post has great information handling these cases.

AIR on Android OS Interactions – Send Email | EverythingFlex: Flex & AIR
Sending email from a mobile app is pretty commonplace. Doing it is well explained by this article by Rich Tretola.

AIR SQLite Optimization tricks | Parametrized SQLStatement | SQLite Transactions | zedia flash blog
Working with IO can be expensive in a mobile application. I didn’t realize how much so until I started doing some bulk inserts of sample data. So I needed some AIR optimization hints. I had forgotten completely about transactions, but luckily for me, this Dominic Gelineau post reminded me.

 

Finicky – a Flex and AIR mobile app

For the past few months, I’ve been working hard on a mobile app called Finicky. It’s a mobile journaling application for tracking hard-to-search-for, local items.

The idea for it came to me in San Francisco. I wanted to smoke. I smoke cloves. (Make your hipster jokes.) However, cloves tend to be a little hard to find. Most convenience stores don’t carry them. The tend to be found in tobacco shops, head shops, and occasionally at a random spot like a newsstand. I tried searching on Google, but it’s hard to get reliable data on which stores stock them. The really frustrating part of this was that I know I had found them before. If only I had somehow kept track of it…

Now a mobile app just for tracking cloves would be overkill. But as I thought about it, there were a lot of things that I would love to track like that. Ever been a Coke/Pepsi fan in a Pepsi/Coke town? Can’t search that out. I like a whole bunch of other specific things. So thus was born Finicky.

I approached this a little different from most of my apps, in that I got design help from the beginning. By design help, I mean a full Photoshop comp and UI treatment. I wanted a different look for my app then I’ve seen with most mobile apps, especially on Android. I wanted something grungy and organic. I know what I wanted, but I don’t know how to design it. So I got help from The1stMovement, a design firm who our team had done work with in the past.

What they designed was beyond my imagination. Hence, why I needed a designer. It’s great looking, it’s got a specific style, and it doesn’t look like anything I’ve seen on a phone.

I took those comps apart and turned them into mobile Flex skins. And here is the result. I am releasing it as an Android app first. Then releasing it as an iOS app. I’m going to have it out on Android, iterate through bug reports as fast as I can, then when I’m sure of stability, get it onto iOS. For now I’m targeting just phones for this app. If it there is interest, I’ll port to tablets.

In any case, find out more and link to downloads at http://finickyapp.com.

Source is available on github