Every time I have to make some icons for an app, I always have to go look up the sizes for each platform. So, I figured I'd make a post with the sizes (including actual-sized boxes, of course), and links to the relevant design documents from each manufacturer.

Apple and Google both provide guidelines for designing application icons, and it's worth checking them both out. They have different approaches to icon composition, since iOS wants each icon to be inside a rounded-square box with a glossy highlight* and drop shadow, and Android encourages taking advantage of the alpha channel and using unique shapes.

• Custom Icon and Image Creation Guidelines - iOS Human Interface Guidelines
• Launcher Icons - Android Icon Design Guidelines

* Technically, you can turn off the glossy highlight on your iOS home screen icon, but most developers seem to leave it on.

	Size	36px Ratio	Uses
	36px	1:1	Android ldpi (basically never used any more)
	48px	4:3	Android mdpi (used on older phones and tablets)
	57px	19:12	iPhone (non-retina display)
	72px	2:1	iPad and Android hdpi (used on most modern phones)
	96px	8:3	Android xhdpi (used on very new phones)
	114px	19:6	iPhone 4+ (retina display)

As a Windows/Linux user who's spending most of his time on OS X these days, there are several little features that I miss. One of them is the ability to create a new file from directly within the file browser (i.e. Finder). Well, I guess I'm not the only one, as I found this awesome little script called "New Text File Here":

http://wisser.me/software/#NewTextFileHere

Just download the .app file, start editing your finder toolbar, and drag the app into an empty space. The current version prompts you for a file name and automatically opens it in a text editor after it's created. Great stuff!!

For some reason, this seems like a difficult thing to google for and can often lead to people doing things the wrong way, so I'll show how simple it is to do PDF rendering in iOS. 

The problem: you have an iPhone or iPad app that does some custom drawing inside a subclass of UIView. Now you want all of your awesome graphics to be exported to a PDF so you can either archive it or share it with people who don't have your app. 

Unfortunately, a lot of people google around for a solution and end up finding some really convoluted examples using CGPDFContextCreateWithURL and making CFDictionaries. While you may be able to come up with a working solution using the CF* and CG* functions, it's not much more complicated than most people need.

Luckily, UIKit has some very handy helper functions in UIKit for doing exactly this. Assuming you're insde a subclass of UIView that does rendering in it's drawRect method, here's how you generate a PDF called fileName at path:

 

NSMutableDictionary *pdfDict = [[NSMutableDictionary alloc] init];
[pdfDict setValue:fileName 
    forKey:(NSString*)kCGPDFContextTitle];
[pdfDict setValue:@"Author of the PDF" 
    forKey:(NSString *)kCGPDFContextAuthor];
[pdfDict setValue:@"App that created the PDF" 
    forKey:(NSString *)kCGPDFContextCreator];
UIGraphicsBeginPDFContextToFile(path, 
    CGRectMake(0, 0, self.bounds.size.width, self.bounds.size.height), 
    pdfDict);
[pdfDict release];
UIGraphicsBeginPDFPage(); 
[self drawRect:self.bounds];
UIGraphicsEndPDFContext();

 

It's that simple. UIGraphicsBeginPDFContextToFile creates a PDF context and sets it as the current UIKit context. Thus, all rendering operations on the current context will be directed to the PDF instead of the screen, until you call UIGraphicsEndPDFContext. The result is a PDF generated with native drawing commands, often much smaller yet better quality than an image capture of the view.

NOTE: If you're rendering text in your UIView, make sure you use text rendering methods like [@"my string": drawAtPoint:] instead of placing UILabels over the view. The labels won't be rendered to the PDF.

When making user interfaces in MonoTouch, as with anything, it's often desirable to create a custom view class to display your content to the user. When using MonoTouch and Interface Builder, this is as easy as:

• Add a UIView to your interface by dragging over the View item from the library
• Go to the Identity tab of the properties panel and change the Class field to the name of your custom class.
• Add your class to the project and make sure it inherits UIView or one of its subclasses.

I've run into a minor problem doing this, but reading around the internet it seems like it might not happen to everyone. If you get an error like:

Unknown class <ClassName> in Interface Builder file.

you simply need to add a MonoTouch.Foundatoin.RegisterAttribute to the class definition, like:

[Register("MyView")]
class MyView : UIView { ... }

 

Last weekend we got bored and threw together a HTML5/Javascript-based online button generator. It's called TinyButtonator, and it lets you define the buttons size, border, rounded corners, and a variety of stylized gradient background. It's written in Javascript and uses the HTML5 Canvas API to do the rendering, all client-side. The buttons can be exported as PNG images with transparent backgrounds. You can also save the button as a permalink to bookmark or send to someone else.

There are a lot of similar websites out there, but none of them quite fit our needs. So we ended up spending a ton of time messing around in Photoshop or Inkscape making simple button images. We want something simple that looks nice, and they're always a bit different. TinyButtonator gives us exactly that. It's totally free, so go ahead and try it out!

 

This week we released the beta version of TinyModeler. It's an in-house domain modeling web application that we've made available to the public through a free beta program. Register for your free account and try it out!

What is Domain Modeling?

Here at Tiny Mission, we use domain modeling all the time. It's a way of capturing the high-level data and business requirements of an application in a concise, graphical format. We use domain modeling as the beginning of the application design process. It allows us to effectively communicate between each other and with customers about what the application is supposed to do.

For a more in-depth overview, check out the Wikipedia page.

What is TinyModeler?

There are some domain modeling tools on the market, mostly taking the form of database design or UML class modeling applications. While some of them perform their function well, we never quite found one that fits our needs:

• Easy to use
• Cross-platform (we use Mac, Linux, and Windows at Tiny Mission)
• Doesn't box us into a specific backend implementation (like the SQL Server database designer or XCode's CoreData modeler)
• Doesn't contain the visual and user interface cruft of most UML design tools

As a result, we decided to write our own. TinyModeler is a web application that uses the HTML5 canvas element to allow you to interact with models right in your browser. It was designed from the ground up to be simple and easy to use, yet have the expressiveness that we need.

What's the Future?

Right now TinyModeler is in beta. This mean's there are a couple missing features and some bugs that still need to be worked out. You can register for a free beta account right now that lets you create and edit two models. Once we do a final release, this account type will still be available, along with a paid upgrade that lets you store more models and have access to some advanced features.

 

shipping-screenshot.png (70.19 kb)

In a previous post, I discussed being able to install Rails 3.0 on Ubuntu 10.04. Today, we'll talk about all the steps necessary to install Rails 3.0 and get it running on Ubuntu 10.10.

Let's start off by installing the necessary packages from apt-get:

sudo apt-get install ruby ruby-dev libsqlite3-dev rubygems

You'll notice that there are some standard ruby packages, as well as the development package for sqlite3. Since sqlite is the default database for new Rails apps, and a really handy development tool since it doesn't require you to setup and maintain a database server on you machine, we'll include this right off the bat. The development files are needed to build the native Ruby extension through rubygems.

Since Ubuntu 10.10 comes with rubygems 1.3.7, it is able to install Rails 3.0 directly, so we won't have to do any trickery like in the last article. We can move right on to installing Rails:

sudo gem install rails

This should list a bunch of gems that are needed by rails as they're being installed, along with the associated documentation. The builder gem's documentation generation might fail with an error, but don't worry. It will still function.

There's one more thing that we have to do before using Rails. Rubygems on Ubuntu installs the executable gem files in /var/lib/gems/1.8/bin, which isn't in your system path by default. This means that we can't run gem executables from the command line until it's added to our path. For a temporary fix, you can do:

export PATH=$PATH:/var/lib/gems/1.8/bin

For a more permanent solution, create a .bashrc file in your home directory and add the previous command to it:

echo 'export PATH=$PATH:/var/lib/gems/1.8/bin' > ~/.bashrc

This assumes that you don't already have a .bashrc file (if it's a fresh install of Ubuntu, you won't). If you do, append the command to the end of the file.

Now we have full access to our gems. To create a new Rails project, go the directory you'd like to have it in and type 'rails generate <app name>', like:

rails generate myapp

Now you can configure the gems you'd like for your app in the Gemfile. For example, say you'd like to be able to use Haml as a markup language instead of the default erb, simply add

gem 'haml'

to Gemfile. Once you're done (and whenever you change this file), run:

bundle install

to automatically install all of the gems the app needs.

Now you're set. To run your app, run:

rails server

and enter http://0.0.0.0:3000 into your browser. You should be greeted by the friendly default Rails page.

 

A recent development in Linux graphics technology has been the release of the Nouveau driver: a completely Open Source, 3D driver for NVIDIA graphics cards. It is meant to replace the proprietary drivers provided by NVIDIA with something that provides all of the source code with an OSI-approved license. 

This is all fine and good, but there's a bit of a problem with the way the new driver is being used. Even though Nouveau is relatively new and hardware/feature support is still developing, several major distributions have decided to include the driver in their new releases. What's more, the driver has been made default for NVIDIA cards. 

This might not be a big deal if Nouveau would at least gracefully degrade to the default Linux VESA driver if it encounters a problem. Unfortunately, this doesn't always seem to be the case. When trying to install the latest version of Linux Mint on one of my machines this weekend, I ran into this exact issue. The live CD booted fine and the installation took place without an issue. However, when I rebooted after the installation, it would get just passed the GRUB screen and then the screen would go blank. Not just a black screen, but the monitor would go into standby since it no longer had a source.

This is pretty disheartening, as this machine (with a Geforce 9400) has been running various forms of Linux for years without any issue. Plus, Linux Mint is hands down my favorite distro due, in part, to its ease of installation.

Thinking it was an issue with the install (I knew the disk was okay since I used it on my wife's laptop the day before), I tried a fresh install, with the same effect. I then tried the Linux Mint Debian Edition, same thing. Getting pretty frustrated, I decided to try the latest RC of Fusion Linux, a distro I haven't tried before but am interested in. This, of course, led to the same effect, since Fusion is based on Fedora, which is one of the distro really pushing the adoption of Nouveau. 

After digging around a bit and trying a couple different things, I fixed the problem by disabling Nouvea on boot, letting it fall back to the default VESA driver, then installing the proprietary driver. If you're running an Ubuntu-based distro, here's how:

1. When the computer boots and you're in the grub screen, pressed 'e' (make sure the correct operating system is selected)
2. This will display the boot options. Add "nouveau.modeset=0" to the end of the line containing "quiet splash". This will disable the Nouveau driver for a single boot.
3. Hit Ctrl-X to boot the machine with the new settings.
4. Your OS should boot using the VESA driver, meaning the display resolution will be pretty poor. That's okay, Ubuntu will notify you that there are proprietary drivers to install. 
5. Install the proprietary NVIDIA drivers and reboot. You should now have a fully-functioning installation.

I happen to be using a Geforce 9400. It's a couple years old, but still quite relevant and useful. Based on my time sifting through the internet looking for possible solutions, I believe that other older-model NVIDIA cards could also be affected.

While I appreciate the effort of the Nouveau developers to give us an Open Source alternative to NVIDIA's closed source drivers, making the installation useless due to unsupported hardware is less than acceptable, especially for those of us who have no moral qualms with using proprietary video divers. I don't know if it's the Nouveau team to blame for poor degradation, or the distros to blame for applying the new driver indiscriminately to all NVIDIA cards, but it's an unfortunate situation.

 

 

If you have the default rubygems package (version 1.3.5) installed on Ubuntu 10.04 and you try to update to the latest Rails release (3.0.x), you'll get a message about needing a later version of rubygems:

ERROR:  Error installing rails:
    bundler requires RubyGems version >= 1.3.6

A simple way to fix this is to install the rubygems-update gem:

% sudo gem install rubygems-upate

Then upate to the latest rubygems with:

% sudo /var/lib/gems/1.8/bin/update_rubygems

Now you should be able to install the latest version of Rails:

% sudo gem install rails

 

I was playing around with WebGL last night, doing some basic demos from the web. As an experienced OpenGL programmer, I was relieved to see how similar the WebGL API is (with some Javascript-specific tuning, of course).

I set about playing around with the excellent tutorials at http://learningwebgl.com. They step through some basic scenes up to some relatively advanced usage.

However, when playing around with the texture tutorial (http://learningwebgl.com/blog/?p=507), it occurred to me that using an existing HTML element like a canvas tag as a texture would be a common use case for this technology. Unfortunately, WebGL is in its infancy and the amount of documentation availabel through a Google search is limited. After looking around for a while, it wasn't obvious how I would accomplish this seemingly simple task.

After a bit of searching and some playing around with the code, I found (to my delight) that the texImage2D function on a WebGL context can be passed a canvas object for rendering. So, instead of passing it an image element like the tutorial shows, you can simply pass a canvas context:

gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, canvas2d);

where canvas2d is a canvas element that's been grabbed from the DOM with something like document.getElementById("canvas"). This should provide a nice way to create rich, 3D content that is generated from the 2D HTML 5 API.

UPDATE: It seems like, at least in the browser that I've been using for testing (Chromium 8.0 on Ubuntu), you can't use NPOT (non-power of two) elements for the texture. This means that the element must have a width and height that is a power of two.