tijo

Archive for 2011|Yearly archive page

wootvetica Updates

In Apps, News on September 24, 2011 at 12:26 pm

Woohoo, wootvetica just passed the 1000 downloads mark! Exactly 1001 as of this morning. Took long enough 🙂

The App is currently the fifth result when searching for “woot” on the App Store and it’s gotten a 4.5/5 rating. All good things.

 

I also released wootvetica 1.1 on the 21st, and it’s gotten around 500 downloads so far which pleases me. 1.1 adds

  • Sharing features
  • The ability to see the discussion links for various products
  • Better parsing of product descriptions (particularly with embedded images)
  • A custom image viewer to provide an in-depth look at products.

I’ve got a slew of features lined up for 1.2 which I’m slowly working on implementing. I’m going to be adding some sort of deferred reminders so that the App doesn’t always bother you late at night, I’ll be switching from OHAttributedLabel to TTTAttributed label, and I’ll be changing the name from wootbetica to Wootie. Push notifications are still in the works for a future release.

 

Let me know what you think and what you’d like to see added or changed!

Advertisements

FaceType

In Apps, Code, Hobby on September 15, 2011 at 3:31 pm

I’ve started getting into typography lately, and while I am still a novice I decided to start building an App showcasing the beauty of fonts. The App is named FaceType, a play on words of both the FaceTime product and the word Typeface. It’s open source, available here on github.

It’s iPad- and portrait-only right now because that’s sort of the way I envisioned it, though I’ve added some hooks in the code to fix that (switching both off doesn’t completely kill the experience right now).

I’ve also started downloading a whole bunch of fonts, mostly from dafont.com, to put in the App. I may add the program I’m using to do that as well in time.

Check it out! It’s pretty. Don’t know if it’s App Store bound or not.

Introducing wootvetica

In Apps on September 3, 2011 at 9:12 am

I’m growing increasingly tired of the time it takes to perform small tasks in Apps on the iOS. CheckIn originally embodied this by making it so you could check in on multiple social networks from one App in seconds flat. NGadget was no slouch here, prefetching content and laying it out to avoid user click (*cough* tap)-throughs left and right as well as caching like crazy. I’m taking the Windows Phone “glance and go” point of view on in future tijo Apps, things should be lightning fast and actively work on behalf of Joe User. I’m launching an App with this in mind today.

Introducing wootvetica, a Woot client with style


The App takes the chromeless styling from NGadget and applies it to daily Woot deals. It targets a few things I hate about other Woot apps.

1. Tabs Tabs Tabs

A lot of Woot Apps silo each Woot channel into a tab, upon launch users have to switch from tab to tab to tab refreshing at each. Upon launching wootvetica all the current deals are shown in the form of tiles complete with image, title, price, shipping and handling, and whether or not the item is sold out. There’s no tab switching and refreshing of individual tabs to see what the deals are, they’re all in one place so you don’t have to tap around. Deals are cached between sessions for offline viewing, and the descriptions of items are displayed with OHAttributedLabels in lieu of UIWebViews so there’s no additional pain there.

2. Forgot to check Woot, missed a deal

Woot deals (usually) turn around at the same time, midnight central time. Trouble is, I usually forget to check Woot for several hours or miss it for several days. I’ve missed deals I would’ve gladly cashed in on because they’ve sold out or I simply waited more than 24 hours to check.

Wootvetica currently takes advantage of the wonderfully low-tech local notification to simply remind users of new Woot deals. Because these are timed notifications this means that I don’t currently support Woot-Off notifications and I’m still unable to show whole product titles in notifications.

In the future I’ll be adding Push Notifications via Parse, and users will be able to be notified of Woot-Offs or new products without even having to open the app. You can turn all notifications off in the settings, naturally.

You can download it for free right here.

iOS Multitasking for Dummies

In Uncategorized on July 10, 2011 at 11:45 am

I’ve had a couple of friends either new to the iOS or looking to buy a new smartphone ask me about multitasking on the iOS with concern. The two thoughts I heard were “are all these apps in the drawer really running?” and “multitasking, doesn’t that mean weird stuff can go on in the background that I can’t control?” It’s funny because multitasking on the iOS is designed to be as hands-off as possible for end users, quite different than desktop apps where we’re constantly aware of what’s running and what isn’t, and where we’re in direct control over the state of every app. Apple’s approach to multitasking on the iOS is meant to insulate consumers from task management and to keep naive developers from hogging resources while in the background like some of the iOS’s competitors.

Answering these two questions:

1. Are all these Apps in the drawer really running?

In short, no, they aren’t. The multitasking drawer is simply a queue of applications that you’ve had running recently, not of those that are presently running. In fact, every App you’ve ever opened will appear in this tray in the order of most recently used. One of the key differentiators between multitasking on the iOS and on Desktop OSes is that the iOS acts as a much stricter resource daemon. Usually only the first 4-10 apps in the drawer will actually be running, and the iOS is keenly aware of which Apps it should terminate and which it shouldn’t. Apps that are resource intensive or haven’t been used recently are automatically terminated by the OS.

2. Multitasking, doesn’t that mean weird stuff can go on in the background that I can’t control?

Not really. Multitasking on the iOS is incredibly restrictive from a developer’s point of view, but it’s for a good reason. Additionally, Apps are always a force-close away from being totally killed, although it shouldn’t ever have to come to this.

I thought I’d give a brief, simplified overview of how multitasking works on the iOS for those concerned parties.

iOS Multitasking for Dummies

There are essentially 4 ways in which an App can handle multitasking on the iOS.

1. Doesn’t run in background

Every version of the iOS prior to iOS 4.0 worked in this way, a couple seconds after you press the home button the App is terminated… easy. I miss these days. Developers can still make their Apps not multitask if they choose, some of mine don’t.

2. “Default”

Every App in the iOS gets this form of multitasking for free, and a majority of Apps don’t go further than this. Apps with the system’s default multitasking do remain existent in the background (unlike 1 above), but they are essentially frozen in carbonite 1-10 seconds after a user presses the home button. They spring to life very quickly when the App is relaunched, but they are not actively capable of doing anything in the background. Furthermore, if the OS is under pressure these Apps can be asked to unload resources in the background or even be terminated completely.

3. Background task execution

Background task execution is great for carrying out short tasks that will take a little bit longer than 1-10 seconds. What this does is grant an App a few minutes (exact number TBD by the OS at the time, about 10 minutes on the iPhone 4) to carry out some outstanding task in the background. The App is slowed down, it’s ability to use resources and the network is degraded, but it will still be capable of running. When the App’s timer is up it is forced into sleep (like 2 above), or it is killed completely if the developer doesn’t do their job right (like 1 above). Think of uploading pictures to Flickr: you launch the App, choose a dozen pics and press “upload”, then got to the homescreen. The App keeps merrily uploading pictures just like you’d expect, but isn’t allowed to run forever.

4. Special services

These Apps are the exception that are given free reign to run in the background, but they’re also not the types of Apps that you would want being terminated or frozen in the background. Think of streaming music, GPS, or VoIP. App developers must register their Apps as one of these services at the time of submission to the App Store, and Apple checks to verify the correctness of the requested permission. This way, a random App couldn’t register as being a fully-privileged GPS App while simply wanting to stay alive in the background.

So there you have, multitasking in the iOS. Don’t worry about it!

Double Tap to Zoom

In Code on March 13, 2011 at 9:29 am

Hello,

My recent work in UX design for the iOS has led me to frustration with many apps out there emulating the Photos.app-like feel for photo viewers. This zooming, panning, gallery view controller is often hard to recreate, and I’m not sure why Apple doesn’t simply provide one (c’mon, Apple), but I’ve noticed that one feature gets left out more than the rest in these third-party reproductions: double tap to zoom. With the introduction of UIGestureRecognizer (specifically UITapGestureRecognizer) in iOS 3.2, integration of this feature is very easy, however many apps still fail to include this feature. I’ve included a code snippet of this in hopes that maybe it will be integrated more often, I’d like to walk through it from a high level.

 

1. On loadView (or viewDidLoad), add a UITapGestureRecognizer to the scrollView on which you’re placing your image to zoom and pan around. Set the minimum number of taps to 2 (i.e. double tap), and point it at a method that takes a UIGestureRecognizer as a parameter (i.e. doubleTap:(UIGestureRecognizer *)recognizer).

2. Within the method created check that (1) the gesture recognizer is the one corresponding to the correct scroll view and (2) that the gesture recognizer is in the UIGestureRecognizerStateEnded state, otherwise you’ll get two zooms for every double tap.

3. After this check, examine the zoomScale of your scroll view. If it is not equal to 1, then set the zoom scale to 1. If it is equal to 1, use the locationInView: method on the gesture recognizer and call zoomToRect: on the scroll view from this location.

 

BOOM! Double tap to zoom in your own, home-made image viewer. Code outlining this is attached.

 

Double Tap To Zoom Code Snippet

CheckIn Woes

In Apps, News on January 7, 2011 at 3:32 pm

Hello all, working in getting a fix in for this CheckIn-Gowalla fiasco. Very sorry I didn’t recognize it sooner! Should have the update submitted by tomorrow, hopefully approved in a week.

 

Update: The fix is complete, submitted, and approved (Has been for a while). Gowalla is Go.