CircuitBee (http://www.circuitbee.com) has been our main focus since earlier this year. Here’s a quick quote from our release post, describing the service and what it does:

Have you ever designed an electronic schematic then wanted to share it on your blog? Or wanted help improving your circuit on a forum? Ever peered at a tiny/massive image of a circuit on a website and wondered why on earth there wasn’t a better alternative?

We have. Back in 2010 we were working on our first major electronics project, the Illuminatrix, an array of 256 RGB LEDs that were to show animations created by people all over the world at the Burning Man festival. It involved using a lot of technology we’d never used before, so we weren’t quite sure about our circuit designs.

We tried posting on blogs and forums trying to explain our schematic and the problems we were having with it. This proved more difficult than we expected: describing a circuit in words is really hard, so we tried to post an image of our schematic instead, and our schematic project files.

This involved a lot of messing around with capturing JPEGs of the schematic and uploading all the project’s symbol libraries and schematic files. But of course people willing to help didn’t necessarily have the right software, or the JPEG was too small to read usefully, or too large to post on many of the forums. We thought that there must be a better way to share schematics, to discuss them, and to show them to people while writing about them. It turned out there wasn’t anything out there that would help us do this, so being the ambitious fools that we are we set out to create it.

CircuitBee is like YouTube for your circuit schematics. You upload your Eagle or KiCAD schematics, we crunch the numbers and create an online embeddable version of your schematic.

Since our release just over a month ago the site has been doing very well. With over 2500 users registered, and 160 circuits uploaded the response from the community has been very encouraging. But, this is keeping us very busy, with lots to do, meetings to be had, and lots of users to respond to, we haven’t had much time to work on anything else. So, if we’re a little absent from the CWD site, then please head over to the CircuitBee site to see what we’re up to!

I’m having to load a great many bitmaps dynamically, and as fast as possible to create a fluid user interface. We’re talking over 1000 bitmaps here, not all at once obviously, but a fair number at one time. I’m loading these files from SD card, so am creating the Bitmaps using the BitmapFactory.decodeStream method to stream them from file:

...
InputStream is = new BufferedInputStream(new FileInputStream(myFile),8096);
Bitmap bmp = BitmapFactory.decodeStream(is,null,options);
...

In doing so I sensibly wrap my input stream in a BufferedInputStream so that I can more efficiently read the data. In fact internally the decodeStream method actually wraps your stream in a BufferedInputStream if you haven’t already. This would normally not be an issue. But since I’m loading many Bitmaps at once, and repeatedly, this is causing a memory allocation issue.

I noticed in my logcat a vast number of garbage collection calls which were drastically slowing down load times. After looking around my source, and the Android source, I concluded that this was due to each Bitmap I loaded caused a byte array to be allocated for the BufferedInputStream.

The solution? Simple really, I created a new class ReusableBufferedInputStream, included below, which is a duplication of the standard BufferedInputStream implementation you can find here. The only changes I’ve made have been to remove the normal constructors which take an input stream and a buffer size, and replace them with a constructor that lets you specify the actual byte array to use as the buffer. This stops the multiple allocations when loading many streams, and has drastically improved the performance of the application.

/**
 *  Licensed to the Apache Software Foundation (ASF) under one or more
 *  contributor license agreements.  See the NOTICE file distributed with
 *  this work for additional information regarding copyright ownership.
 *  The ASF licenses this file to You under the Apache License, Version 2.0
 *  (the "License"); you may not use this file except in compliance with
 *  the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software
 *  distributed under the License is distributed on an "AS IS" BASIS,
 *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *  See the License for the specific language governing permissions and
 *  limitations under the License.
 */

/**
 * NOTICE: This class is a modification of the original BufferedInputStream
 * source code found at:
 *
 * http://android.git.kernel.org/?p=platform/libcore.git;a=blob;f=luni/src/main/java/java/io/BufferedInputStream.java;hb=HEAD
 *
 * Modifications have been made to allow buffers to be specified directly
 * thus avoiding memory allocations.
 *
 * Any questions/comments should be directed to ben@cwd.co.uk.
 */
package novoda.weeworld.assetpackmanager;

import java.io.FilterInputStream;
import java.io.IOException;
import java.io.InputStream;

/**
 * A duplication of the {@link BufferedInputStream} class. The only difference being
 * this version allows a buffer to be specified directly. This can be used to very
 * effectively avoid repeated allocations of buffers. Thus massively increasing
 * performance by eliminating garbage collection.
 *
 * The following is from the BufferedInputStream documentation:
 *
 * Wraps an existing {@link InputStream} and <em>buffers</em> the input.
 * Expensive interaction with the underlying input stream is minimized, since
 * most (smaller) requests can be satisfied by accessing the buffer alone. The
 * drawback is that some extra space is required to hold the buffer and that
 * copying takes place when filling that buffer, but this is usually outweighed
 * by the performance benefits.
 *
 * <p/>A typical application pattern for the class looks like this:<p/>
 *
 * <pre>
 * byte[] myBuffer = new byte[16*1024];
 * ReusableBufferedInputStream buf = new ReusableBufferedInputStream(new FileInputStream(&quot;file.java&quot;),myBuffer);
 * </pre>
 *
 * @see BufferedInputStream
 */
public class ReusableBufferedInputStream extends FilterInputStream {
    /**
     * The buffer containing the current bytes read from the target InputStream.
     */
    protected volatile byte[] buf;

    /**
     * The total number of bytes inside the byte array {@code buf}.
     */
    protected int count;

    /**
     * The current limit, which when passed, invalidates the current mark.
     */
    protected int marklimit;

    /**
     * The currently marked position. -1 indicates no mark has been set or the
     * mark has been invalidated.
     */
    protected int markpos = -1;

    /**
     * The current position within the byte array {@code buf}.
     */
    protected int pos;

    /**
     * Constructs a new {@code ReusableBufferedInputStream}, providing {@code in} with a buffer
     * of 8192 bytes.
     *
     * <p><strong>Warning:</strong> passing a null source creates a closed
     * {@code BufferedInputStream}. All read operations on such a stream will
     * fail with an IOException.
     *
     * @param in the {@code InputStream} the buffer reads from.
     * @param buffer {@code byte[]} to use as the buffer.
     */
    public ReusableBufferedInputStream(InputStream in, byte[] buffer) {
        super(in);
        if (buffer==null) {
        	throw new NullPointerException("Buffer argument is null");
        }
        buf = buffer;
    }

    /**
     * Returns an estimated number of bytes that can be read or skipped without blocking for more
     * input. This method returns the number of bytes available in the buffer
     * plus those available in the source stream, but see {@link InputStream#available} for
     * important caveats.
     *
     * @return the estimated number of bytes available
     * @throws IOException if this stream is closed or an error occurs
     */
    @Override
    public synchronized int available() throws IOException {
        InputStream localIn = in; // 'in' could be invalidated by close()
        if (buf == null || localIn == null) {
            throw streamClosed();
        }
        return count - pos + localIn.available();
    }

    private IOException streamClosed() throws IOException {
        throw new IOException("ReusableBufferedInputStream is closed");
    }

    /**
     * Closes this stream. The source stream is closed and any resources
     * associated with it are released.
     *
     * @throws IOException
     *             if an error occurs while closing this stream.
     */
    @Override
    public void close() throws IOException {
        buf = null;
        InputStream localIn = in;
        in = null;
        if (localIn != null) {
            localIn.close();
        }
    }

    private int fillbuf(InputStream localIn, byte[] localBuf)
            throws IOException {
        if (markpos == -1 || (pos - markpos >= marklimit)) {
            // Mark position not set or exceeded readlimit
            int result = localIn.read(localBuf);
            if (result > 0) {
                markpos = -1;
                pos = 0;
                count = result == -1 ? 0 : result;
            }
            return result;
        }
        if (markpos == 0 && marklimit > localBuf.length) {
            // Increase buffer size to accommodate the readlimit
            int newLength = localBuf.length * 2;
            if (newLength > marklimit) {
                newLength = marklimit;
            }
            byte[] newbuf = new byte[newLength];
            System.arraycopy(localBuf, 0, newbuf, 0, localBuf.length);
            // Reassign buf, which will invalidate any local references
            // FIXME: what if buf was null?
            localBuf = buf = newbuf;
        } else if (markpos > 0) {
            System.arraycopy(localBuf, markpos, localBuf, 0, localBuf.length
                    - markpos);
        }
        // Set the new position and mark position
        pos -= markpos;
        count = markpos = 0;
        int bytesread = localIn.read(localBuf, pos, localBuf.length - pos);
        count = bytesread <= 0 ? pos : pos + bytesread;
        return bytesread;
    }

    /**
     * Sets a mark position in this stream. The parameter {@code readlimit}
     * indicates how many bytes can be read before a mark is invalidated.
     * Calling {@code reset()} will reposition the stream back to the marked
     * position if {@code readlimit} has not been surpassed. The underlying
     * buffer may be increased in size to allow {@code readlimit} number of
     * bytes to be supported.
     *
     * @param readlimit
     *            the number of bytes that can be read before the mark is
     *            invalidated.
     * @see #reset()
     */
    @Override
    public synchronized void mark(int readlimit) {
        marklimit = readlimit;
        markpos = pos;
    }

    /**
     * Indicates whether {@code ReusableBufferedInputStream} supports the {@code mark()}
     * and {@code reset()} methods.
     *
     * @return {@code true} for ReusableBufferedInputStreams.
     * @see #mark(int)
     * @see #reset()
     */
    @Override
    public boolean markSupported() {
        return true;
    }

    /**
     * Reads a single byte from this stream and returns it as an integer in the
     * range from 0 to 255. Returns -1 if the end of the source string has been
     * reached. If the internal buffer does not contain any available bytes then
     * it is filled from the source stream and the first byte is returned.
     *
     * @return the byte read or -1 if the end of the source stream has been
     *         reached.
     * @throws IOException
     *             if this stream is closed or another IOException occurs.
     */
    @Override
    public synchronized int read() throws IOException {
        // Use local refs since buf and in may be invalidated by an
        // unsynchronized close()
        byte[] localBuf = buf;
        InputStream localIn = in;
        if (localBuf == null || localIn == null) {
            throw streamClosed();
        }

        // Are there buffered bytes available?
        if (pos >= count && fillbuf(localIn, localBuf) == -1) {
            return -1; // no, fill buffer
        }
        // localBuf may have been invalidated by fillbuf
        if (localBuf != buf) {
            localBuf = buf;
            if (localBuf == null) {
                throw streamClosed();
            }
        }

        // Did filling the buffer fail with -1 (EOF)?
        if (count - pos > 0) {
            return localBuf[pos++] & 0xFF;
        }
        return -1;
    }

    /**
     * Reads at most {@code length} bytes from this stream and stores them in
     * byte array {@code buffer} starting at offset {@code offset}. Returns the
     * number of bytes actually read or -1 if no bytes were read and the end of
     * the stream was encountered. If all the buffered bytes have been used, a
     * mark has not been set and the requested number of bytes is larger than
     * the receiver's buffer size, this implementation bypasses the buffer and
     * simply places the results directly into {@code buffer}.
     *
     * @param buffer
     *            the byte array in which to store the bytes read.
     * @param offset
     *            the initial position in {@code buffer} to store the bytes read
     *            from this stream.
     * @param length
     *            the maximum number of bytes to store in {@code buffer}.
     * @return the number of bytes actually read or -1 if end of stream.
     * @throws IndexOutOfBoundsException
     *             if {@code offset < 0} or {@code length < 0}, or if
     *             {@code offset + length} is greater than the size of
     *             {@code buffer}.
     * @throws IOException
     *             if the stream is already closed or another IOException
     *             occurs.
     */
    @Override
    public synchronized int read(byte[] buffer, int offset, int length) throws IOException {
        // Use local ref since buf may be invalidated by an unsynchronized
        // close()
        byte[] localBuf = buf;
        if (localBuf == null) {
            throw streamClosed();
        }
        // avoid int overflow
        // BEGIN android-changed
        // Exception priorities (in case of multiple errors) differ from
        // RI, but are spec-compliant.
        // made implicit null check explicit, used (offset | length) < 0
        // instead of (offset < 0) || (length < 0) to safe one operation
        if (buffer == null) {
            throw new NullPointerException("buffer == null");
        }
        if ((offset | length) < 0 || offset > buffer.length - length) {
            throw new IndexOutOfBoundsException();
        }
        // END android-changed
        if (length == 0) {
            return 0;
        }
        InputStream localIn = in;
        if (localIn == null) {
            throw streamClosed();
        }

        int required;
        if (pos < count) {
            // There are bytes available in the buffer.
            int copylength = count - pos >= length ? length : count - pos;
            System.arraycopy(localBuf, pos, buffer, offset, copylength);
            pos += copylength;
            if (copylength == length || localIn.available() == 0) {
                return copylength;
            }
            offset += copylength;
            required = length - copylength;
        } else {
            required = length;
        }

        while (true) {
            int read;
            //
            // If we're not marked and the required size is greater than the
            // buffer, simply read the bytes directly bypassing the buffer.
            //
            if (markpos == -1 && required >= localBuf.length) {
                read = localIn.read(buffer, offset, required);
                if (read == -1) {
                    return required == length ? -1 : length - required;
                }
            } else {
                if (fillbuf(localIn, localBuf) == -1) {
                    return required == length ? -1 : length - required;
                }
                // localBuf may have been invalidated by fillbuf
                if (localBuf != buf) {
                    localBuf = buf;
                    if (localBuf == null) {
                        throw streamClosed();
                    }
                }

                read = count - pos >= required ? required : count - pos;
                System.arraycopy(localBuf, pos, buffer, offset, read);
                pos += read;
            }
            required -= read;
            if (required == 0) {
                return length;
            }
            if (localIn.available() == 0) {
                return length - required;
            }
            offset += read;
        }
    }

    /**
     * Resets this stream to the last marked location.
     *
     * @throws IOException
     *             if this stream is closed, no mark has been set or the mark is
     *             no longer valid because more than {@code readlimit} bytes
     *             have been read since setting the mark.
     * @see #mark(int)
     */
    @Override
    public synchronized void reset() throws IOException {
        // BEGIN android-changed
        //
        // These exceptions get thrown in some "normalish" circumstances,
        // so it is preferable to avoid loading up the whole big set of
        // messages just for these cases.
        //
        if (buf == null) {
            throw new IOException("Stream is closed");
        }
        if (-1 == markpos) {
            throw new IOException("Mark has been invalidated.");
        }
        // END android-changed
        pos = markpos;
    }

    /**
     * Skips {@code amount} number of bytes in this stream. Subsequent
     * {@code read()}'s will not return these bytes unless {@code reset()} is
     * used.
     *
     * @param amount
     *            the number of bytes to skip. {@code skip} does nothing and
     *            returns 0 if {@code amount} is less than zero.
     * @return the number of bytes actually skipped.
     * @throws IOException
     *             if this stream is closed or another IOException occurs.
     */
    @Override
    public synchronized long skip(long amount) throws IOException {
        // Use local refs since buf and in may be invalidated by an
        // unsynchronized close()
        byte[] localBuf = buf;
        InputStream localIn = in;
        if (localBuf == null) {
            throw streamClosed();
        }
        if (amount < 1) {
            return 0;
        }
        if (localIn == null) {
            throw streamClosed();
        }

        if (count - pos >= amount) {
            pos += amount;
            return amount;
        }
        long read = count - pos;
        pos = count;

        if (markpos != -1) {
            if (amount <= marklimit) {
                if (fillbuf(localIn, localBuf) == -1) {
                    return read;
                }
                if (count - pos >= amount - read) {
                    pos += amount - read;
                    return amount;
                }
                // Couldn't get all the bytes, skip what we read
                read += (count - pos);
                pos = count;
                return read;
            }
        }
        return read + localIn.skip(amount - read);
    }
}

You can then use this new class like so:

...
// allocate a buffer we'll reuse
byte[] reusableBuffer = new byte[16*1024];
...
InputStream is = new ReusableBufferedInputStream(new FileInputStream(myFile),reusableBuffer);
Bitmap bmp = BitmapFactory.decodeStream(is,null,options);
...

I take no credit for the implementation of this class (its just a copy and paste job, since I want the same functionality), I only added the new constructor and name. I have to say, having the source code for Android available for me to browse through has really helped me optimise my apps lately. I hope this little post proves useful to somebody.

Today we finished polishing off our Unicode Keyboard and released it on the Android Market for 99p or thereabouts. This supplementary keyboard lets you input any Unicode character or symbol on your Android device directly. Without having to copy and paste or switch applications or any of that nonsense.

Need a character? Perhaps you want to tweet your latest chess move? (♜ to ♕3) or confess your undying ♥ for ☃. Then you need Unicode Keyboard. When ever you need a Unicode character simply switch your input method to the keyboard. You can then dial in the character you want, select from recently used symbols, or browse or search the entire range of Unicode. Once you’ve inserted the symbols you want, hit the handy key to switch back to your other input methods.

We hope you like it, here’s some screenshots, and you can find it on the Android Market here.

Oh and we documented our build, so you can read about how we did it in these posts:

• Making of Unicode Keyboard #1
• Making of Unicode Keyboard #2
• Making of Unicode Keyboard #3
• Making of Unicode Keyboard #4

Let us know what you think in the comments, and be sure to rate it on the Market!

The keyboard is an implementation of an InputMethodService (often known as an IME). The keyboard runs as service, as such it doesn’t have ordinary windowing setup. So when you try and launch a dialog, you get a big fat NullPointerException related to a Window. This exception isn’t all that helpful since it seems unrelated to the dialog being shown.

It is of course due to the fact that you’re launching it from what is essentially a service. In order to make our dialog work we need to give its window the appropriate type and make it focusable. This can be done quite easily with the following snippet:

    	Window window = dialog.getWindow();
    	WindowManager.LayoutParams lp = window.getAttributes();
    	lp.height = WindowManager.LayoutParams.FILL_PARENT;
    	lp.width = WindowManager.LayoutParams.FILL_PARENT;
    	lp.token = this.mInputView.getWindowToken();
    	lp.type = WindowManager.LayoutParams.TYPE_APPLICATION_ATTACHED_DIALOG;
    	window.setAttributes(lp);
    	window.addFlags(WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM);

    	dialog.show();

With this fix we could finally show dialogs from within an IME. This made it possible for us to show a popup dialog letting you browse all the code blocks within Unicode and select characters that way.

In order to do this we showed a view in the dialog that contained a ViewFlipper holding two ListViews. The first ListView showed all the code blocks retrieved from the database, when clicked we flipped the view to show the second ListView. This view was populated with an adapter containing all the characters retrieved from the database in the selected code block range. This made for a nice interface since we could switch back and forth between the two views and keep our place within the code blocks list allowing for a smooth browsing experience. I’ll go into exactly how all that is implemented if necessary, but I think ListViews and Adapters have been covered to death online already.

So it just remains for us to polish off the fine details, improve the styling a little, and create the relevant Android Market assets. Hopefully we’ll release this by Wednesday this week. Stay tuned for a post with screenshots of the final product.

In order to do that, we really want to know what characters are being entered as the Unicode range is huge and users can’t be expected to remember all those hex codes. So we created a database of all the Unicode codepoints, and inserted that into our application and used it to lookup the codes as they were entered to get the textual name of the dialed in character. This is also helpful since the default Android fonts don’t support most of Unicode and characters show up as square blocks, so its nice to show users what they’re entering when they can’t actually see it.

Thankfully Unicode provide various files describing all the characters, we used one they call NamesList. This describes all the characters and their alternative names. Obviously we can’t use this file as-is, so we converted it into a CSV file that can be imported into an SQLite database. This turned out to be a relatively straightforward task. In fact our resident tester, designer, grumbler and general odd-job-man Ted managed to code this up in PHP in a few hours and he claims not to be able to code at all!

We ended up arranging our CSV file with the integer value of the codepoint for the character, followed by the official name for the character, then the alternative names all separated by tabs:

...
117    LATIN SMALL LETTER U
118    LATIN SMALL LETTER V
119    LATIN SMALL LETTER W
120    LATIN SMALL LETTER X
121    LATIN SMALL LETTER Y
122    LATIN SMALL LETTER Z
123    LEFT CURLY BRACKET    OPENING CURLY BRACKET, left brace, opening curly bracket
124    VERTICAL LINE    VERTICAL BAR, vertical bar
125    RIGHT CURLY BRACKET    CLOSING CURLY BRACKET, right brace, closing curly bracket
126    TILDE
...

This format is rather handy, since we can just import it directly into an SQLite database. Due to the integer field being first we can also use this as the primary key for our table, that makes lookups really fast. For our app we’ve also converted the Blocks file into a similar format so that we can have a list of all the code blocks within Unicode to make our browsing experience nicer.

If you haven’t got SQLite yet you should go download it here. We used the following commands to create our database tables and import our data:

CREATE TABLE codepoints (_id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE codeblocks (_id INTEGER PRIMARY KEY, name TEXT NOT NULL, lowerRange INTEGER NOT NULL, upperRange INTEGER NOT NULL);
 CREATE TABLE "android_metadata" ("locale" TEXT DEFAULT 'en_US');
INSERT INTO "android_metadata" VALUES ('en_US');
.separator \t
.import UnicodeData.csv codepoints
.import UnicodeBlocks.csv codeblocks

Couple of things to note here, we named our primary key fields ‘_id‘, thats to make it compatible with Android since it will look for this field in our tables. We’ve also added an ‘android_metadata‘ table, this is also required by Android. We’ve then set the separator and imported our CSV files into our tables. We now have a database of all the Unicode information we need to create a nice browse and search experience.

Next up we needed to add our database as an asset for our application, and have it copied into place when our app starts for the first time. There’s a handy little class called SQLiteOpenHelper which we’re going to extend to do most of our database access, and we’ll add our copy behaviour to that. Juan-Manuel Fluxà made this great post about how to extend this class to copy databases from your assets folder. We based most of our database code off this so go take a look, but we did find we had to fix one small issue. Before each call to getReadableDatabase() in his class we added a call to close(). This fixes a rather odd bug that crops up on first installation of the database, it appears something ends up in an incorrect state causing an exception, but a quick call to close fixes that.

So when our keyboard is started, we need to copy over the database if necessary, and open up a connection to it. We added a call to createDatabase and openDatabase in our onCreate method to accomplish this:

    @Override public void onCreate() {
        super.onCreate();
        mWordSeparators = getResources().getString(R.string.word_separators);
        dbHelper = new DatabaseHelper(this);

        try {

        	dbHelper.createDataBase();

        	dbHelper.openDataBase();
	 	} catch (IOException ioe) {
	 		throw new Error("Unable to create database");
	 	}
    }

We also added some methods to our database helper that let us search and list entries from the database. This seemed like a convenient place to store these, and they’re relatively simple queries :

    public String getName(int codepoint) {
    	Cursor cursor = myDataBase.query(TABLE, new String[] { "_id", "name" }, "_id = " + String.valueOf(codepoint), null, null, null, null);
    	if (cursor.moveToFirst()) {
    		return cursor.getString(1);
    	}
    	return "Unknown";
    }
    public ArrayList<CodeBlock> getCodeBlocks() {
    	ArrayList<CodeBlock> codeBlocks = new ArrayList<CodeBlock>();

    	Cursor cursor = myDataBase.query(BLOCKSTABLE, new String[] { "_id", "name", "lowerRange", "upperRange" }, null, null, null, null, null);
    	if (cursor.moveToFirst()) {
    		do {
    			CodeBlock newBlock = new CodeBlock();
    			newBlock.id = cursor.getInt(0);
    			newBlock.name = cursor.getString(1);
    			newBlock.lowerRange = cursor.getInt(2);
    			newBlock.upperRange = cursor.getInt(3);
    			codeBlocks.add(newBlock);
    		} while (cursor.moveToNext());
    	}
    	return codeBlocks;
    }

    public ArrayList<CodePoint> getCodePoints(int lowerRange, int upperRange) {
    	ArrayList<CodePoint> codePoints = new ArrayList<CodePoint>();

    	Cursor cursor = myDataBase.query(TABLE, new String[] { "_id", "name" }, "_id >= " + String.valueOf(lowerRange) + " AND _id <= " + String.valueOf(upperRange), null, null, null, null);
    	if (cursor.moveToFirst()) {
    		do {
    			CodePoint newPoint= new CodePoint();
    			newPoint.codepoint = cursor.getInt(0);
    			newPoint.name = cursor.getString(1);
    			codePoints.add(newPoint);
    		} while (cursor.moveToNext());
    	}
    	return codePoints;
    }

These let us list our entries from the codeblocks database, and lookup entries from the relevant ranges as well as lookup individual codepoints. We added added a call to the getName() method to our handleHexChar method so that we could lookup the character every time we dialled in a new character:

private void handleHexChar(int code) {
    // if the character is a hex character append the char to our existing value
    if (isHexChar(code)) {
        // codepoint stores our currently dialled in number
        String hex = Integer.toHexString(this.codepoint);
        if (hex.length() >= 5) {
            // only want to enter up to 5 hex characters
            return;
        }
        hex += String.valueOf((char)code);
        // convert back into an integer
        this.codepoint = Integer.parseInt(hex,16);
        // uppercase for display purposes
        hex = hex.toUpperCase();
        // convert codepoint into an actual unicode character as a string
        int[] cp = {codepoint};
        String s = new String(cp,0,1);

        // lookup the name for the character
    	String name = dbHelper.getName(codepoint);

        // add the unicode character onto our string for display in the preview area
        // output in the form 'U+2605 ★ Black Star'
        this.mPreviewView.setText("U+" + hex + " " + s + " " + name);
    }
}

So I guess that covers the basics of how to setup a working SQLite database from a pre-existing asset. We now have a working keyboard and can now see what character we’re entering even though Unicode support on Android is patchy at best. In the next post we’re going to cover something slightly more tricky, showing dialogs within a keyboard, this proved non-trivial as the keyboard isn’t your standard activity and so doesn’t behave quite the same when showing dialogs. More on that next time…

Today we’re going to attempt to get the new UI we’ve made to send its keypresses to our own EditText area in which we will show the currently dialed in Unicode character.

Normally keypresses from the Keyboard end up going to the SoftKeyboard.onKey method which then passes them off to various other functions such as handleBackspace or handleCharacter. Thats all well and good for most normal keyboards. For a Unicode Keyboard however we want to dial in a Unicode codepoint (e.g. U+2605) and then when we have selected the right character we want to send it to the editing view.

    public void onKey(int primaryCode, int[] keyCodes) {
    	if (this.mCurKeyboard == this.mUnicodeKeyboard && primaryCode != 10) {
    		// send the key to the unicode preview view and build up our codepoint
    		handleUnicode(primaryCode);
    		return;
    	}
        // continue with previous implementation
        ...
    }

In this snippet we’ve detected when we’re using the unicode keyboard view, and sent our characters off to another function: handleUnicode. Note we’ve detected the case of hitting the ‘Enter’ key (keycode == 10) however, and are going to send that one through the normal functionality. Thats so that the Enter key still moves us between input boxes as a normal keyboard would. Here’s our implementation for the handleUnicode function.

    private void handleHexChar(int code) {
    	// if the character is a hex character append the char to our existing value
    	if (isHexChar(code)) {
            // codepoint stores our currently dialled in number
        	String hex = Integer.toHexString(this.codepoint);
	    	if (hex.length() >= 5) {
                // only want to enter up to 5 hex characters
	    		return;
	    	}
	    	hex += String.valueOf((char)code);
	    	// convert back into an integer
	    	this.codepoint = Integer.parseInt(hex,16);
            // uppercase for display purposes
    	    hex = hex.toUpperCase();
            // convert codepoint into an actual unicode character as a string
            int[] cp = {codepoint};
            String s = new String(cp,0,1);
            // add the unicode character onto our string for display in the preview area
            // output in the form 'U+2605 ★'
            this.mPreviewView.setText("U+" + hex + " " + s);
    	}
    }

Now when we tap the keys on our unicode keyboard, they should get sent to our EditText area (mPreviewArea) and allow us to select our Unicode codepoint. Next we need to make the send button functional, so we’ll add an onClickListener to our onCreateInputView function for the button and point it to our sendUnicode function.

    private void sendUnicode(int codepoint) {
    	int[] cp = {codepoint};
    	String s = new String(cp,0,1);
        // getCurrentInputConnection returns a connection through which we can send
        // the character to the editing view
    	this.getCurrentInputConnection().commitText(s, 1);
    }

We now have a functional keyboard! We can dial in characters and send them to our editing view.

In the next post we’ll start looking at how we’re going to browse the list of unicode characters so we don’t have to remember the codepoints. We’ll back the keyboard with an SQLite database, and use this to lookup the names of our characters as we dial them in as well.

First off, I’m going to assume you know what Unicode is. If you don’t then head over here to read a great explanation from the people that manage it. We’re going to be aiming to create a keyboard that lets us input any character from Unicode version 6. That means we’ll need to be able to easily and quickly enter a series of hexadecimal characters like U+2605 (Black Star). We’ll also want  a list of recently used characters so we don’t have to remember the codes, and maybe some kind of browse and search mechanism so we can easily find characters without having to look them up online.

Here’s a quick sketch of the basic UI we want to make:

A sketch of the user interface for the Unicode Keyboard

This is just a rough draft, we’ll refine it later but it gives you a general idea of what we’re aiming at. As you can see we have a text view above our keyboard that shows the currently selected Unicode symbol, a block on the left that lets you quickly select a recently used symbol, and a hex keypad on the right for selecting a new symbol. We’ve also got search, backspace and a few other buttons. The way we’ll use this keyboard is to dial in the code for the symbol we want, then hit the tick button on the right to send it to the input area that we’re currently editing. This is a bit of a variation from most normal keyboards that send their keypresses directly to the editing view.

Getting Started

The best place to start when developing a software keyboard would be the SoftKeyboard sample provided in the Android SDK. This implements a basic Latin QWERTY keyboard using most of the built in classes and it provides a good base if you’re creating a keyboard that is in any way ‘normal’. Also of use are the documentation pages for the classes in the InputMethodService package. We’ll start off by cloning the SoftKeyboard sample, and then we’ll modify it to suit our purposes.

One word of warning before we get going. This isn’t a walkthrough, so I’m not going to detail every single thing that needs doing to make the code compile and the project work. I’ll give you the broad strokes and expect you to fill in the little details. I’ve always been a great believer in figuring stuff out for yourself, so this isn’t going to be a copy/paste style tutorial.

First we’re going to create a new layout that is going to house our new user interface. The standard mechanism within the sample uses the XML file /res/xml/qwerty.xml to define all the keys in the keyboard, the characters shown on them, the keycodes they send and the basic layout spacings. This XML file isn’t a standard layout file like we see elsewhere in Android projects, its a specialised version that the Keyboard and Keyboard.Key classes parse to create and setup the KeyboardView. We’re going to copy the qwerty.xml and create our own new unicode.xml variation that specifies all the keys we’ll use for our hex input and our recently used character buttons.

The standard KeyboardView provides no way for us to add a TextView to this layout as the KeyboardView is just a specialised view class that has code to render the keys in its own drawing methods. So instead of making an entirely new KeyboardView class from scratch, we’re going to reuse the existing functionality for the normal keys within our keyboard, and wrap that view in a layout that gives us the other views we need. We’ll do this by modifying the /res/layout/input.xml file and wrapping the LatinKeyboardView element within a LinearLayout that will let us position our TextView that will show us what Unicode character we have currently selected. Something like this:

<LinearLayout
	xmlns:android="http://schemas.android.com/apk/res/android"
	android:id="@+id/wrapper"
	android:layout_alignParentBottom="true"
	android:layout_width="match_parent"
	android:orientation="vertical"
	android:layout_height="wrap_content">
    <RelativeLayout android:layout_height="wrap_content"
    				android:layout_width="wrap_content"
    				android:id="@+id/relativeLayout1"
    				android:background="@drawable/charbar_back">
        <ImageButton android:id="@+id/btn_send"
        				android:layout_width="wrap_content"
        				android:layout_height="wrap_content"
        				android:layout_alignParentRight="true"
        				android:layout_marginLeft="3dip"
        				android:background="@drawable/bar_button"
        				android:layout_centerVertical="true"
        				android:src="@drawable/sym_keyboard_addchar"></ImageButton>
        <ImageButton android:id="@+id/btn_backspace"
        				android:layout_width="wrap_content"
        				android:layout_height="wrap_content"
        				android:layout_toLeftOf="@id/btn_send"
        				android:layout_marginLeft="3dip"
        				android:src="@drawable/sym_keyboard_delete"
        				android:layout_centerVertical="true"
        				android:background="@drawable/bar_button"></ImageButton>
        <TextView style="@style/hexBar" android:layout_width="wrap_content"
        				android:layout_height="wrap_content"
        				android:id="@+id/preview"
        				android:layout_toLeftOf="@id/btn_backspace"
        				android:layout_alignParentLeft="true"
        				android:layout_centerVertical="true"
        				android:hint="@string/charbar_hint"
        				android:background="@drawable/charbar_textfield"
        				android:textColor="@color/charbar_text"
        				android:cursorVisible="false"></TextView>
    </RelativeLayout>
	<com.example.android.softkeyboard.LatinKeyboardView
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:id="@+id/keyboard"
        android:layout_alignParentBottom="true"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        />
</LinearLayout>

If you compare this to the original /res/layout/input.xml file you will see that we’ve kept the original LatinKeyboardView element, but we’ve wrapped it in a LinearLayout, and added a RelativeLayout above it that contains our text view and some buttons for sending the character and deleting mistakes.

In order for the new view to show and not cause a nasty crash we’re going to have to modify the SoftKeyboard.onCreateInputView method so that it returns the LinearLayout rather than just the LatinKeyboardView as it does right now:

    @Override public View onCreateInputView() {
    	LinearLayout layout = (LinearLayout)getLayoutInflater().inflate(
                R.layout.input, null);
    	mLayoutView = layout;
        mInputView = (KeyboardView)layout.findViewById(R.id.keyboard);
        mInputView.setKeyboard(mUnicodeKeyboard);
        return mLayoutView;
    }

Finally, in order to get the new keyboard to show we need to add some new lines to our SoftKeyboard.onInitializeInterface method to create the new keyboard from the unicode.xml file:

        mQwertyKeyboard = new LatinKeyboard(this, R.xml.qwerty);
        mUnicodeKeyboard = new UniKeyboard(this, R.xml.unicode);
        mSymbolsKeyboard = new LatinKeyboard(this, R.xml.symbols);
        mSymbolsShiftedKeyboard = new LatinKeyboard(this, R.xml.symbols_shift);

We have to add our new UniKeyboard class which is just an extension of the LatinKeyboard that came with the sample. It doesn’t do anything right now but it will come in useful later on:

package com.example.android.softkeyboard;

import java.util.ArrayList;

import android.content.Context;
import android.content.res.Resources;
import android.content.res.XmlResourceParser;
import android.inputmethodservice.Keyboard.Key;
import android.inputmethodservice.Keyboard.Row;

public class UniKeyboard extends LatinKeyboard {
    public UniKeyboard(Context context, int xmlLayoutResId) {
        super(context, xmlLayoutResId);
    }

    public UniKeyboard(Context context, int layoutTemplateResId,
            CharSequence characters, int columns, int horizontalPadding) {
        super(context, layoutTemplateResId, characters, columns, horizontalPadding);
    }
}

We’ll also need to decide when to show our keyboard, for now we’re just going to always show it so that we can get this part of it working during our testing. So at the end of our SoftKeyboard.onStartInput method we’ll insert the following line:

        mCurKeyboard = mUnicodeKeyboard;
        // Update the label on the enter key, depending on what the application
        // says it will do.
        mCurKeyboard.setImeOptions(getResources(), attribute.imeOptions);
    }

That should be enough hints to get you to a point where you can load your own custom keyboard layout, and add some additional views as furniture around it. In my next post I’ll detail how we make the keycodes from our new keyboard buttons go to the right place, and how we eventually send the character to the input view that is being edited by the IME.

Look for the next posts in the coming days, while the project may only take us the next 3 days to implement it appears that writing blog posts could take considerably longer!

Will and Kate looking pixellated

Some people got married this weekend and this means we have a nice long bank holiday. Sadly my other half is stuck having to finish lots of coursework at the moment (see her progress over at sew.ciety when she has time to update it). This means we’re stuck inside and can’t go off to enjoy the weekend with all the other revellers. So in honour of the new CWD website we decided we’d spend the weekend creating a Unicode Keyboard for Android.

Our chief tester has a pet love for the Unicode Character ‘HOT BEVERAGE’ (U+2615)…

☕

(If that appears as a square block to you then you’re probably using Chrome or Safari, these browsers apparently don’t do fallback fonts properly right now, try looking at it in FireFox)

But he’s found it really hard to express his ♥ for his hot beverage of choice on his Android phone. So we decided we’d solve this issue for him this weekend.

The next few posts will document how we did this and should culminate in the release of the Unicode Keyboard app for you to try out yourself at the end of the bank holiday.

I’ve released two new updates since my last post, both fairly minor bug fixes, though I also added capability for users to create their own outfits and backgrounds in the paid version of the app. This saw a significant uptick in the number of sales of the paid version, from barely one sale per day to somewhere in the region of 3-5 sales per day. Definitely a lesson to be learnt here – if you’re going to have a free version of your app, ensure there’s significant value in the paid version to justify the upsell.

I’ve also been experimenting with launch days and timings. Since the app has very little marketing and hasn’t managed to get ‘featured’ the visibility boost it gets from a new update is quite significant. However the competition for space in the ‘Just In’ lists on the Android Market is fierce, with somewhere in the region of 20-30 apps appearing there every day. So I’ve been experimenting with which day is best to launch on, initially trying out a Thursday afternoon launch, a Saturday release, and a Sunday release. They all work fairly well to be honest, but I think Sunday has a slight edge given that the number of apps added to the Just In list is fewer on a Sunday so your app remains visible for longer.

So, some stats…as of the time of writing the free version of the app has been installed just over 28,000 times. I feel thats quite good considering the lack of significant marketing effort and the fact its only been out for a month. Its now also had just over 100 purchases of the paid version. Total earnings therefore are still pretty low, more beer money levels than rent money levels, but every little helps.

Whats next? Well, there’s certainly more updates to be done on PinMan, and there have been many requests for additional features from users. I also have a couple of other games in mind which I would hope would do better than PinMan by virtue of being more of a traditional game style than the very casual style used in PinMan. I think I shall also spend some time improving my graphic design skills, as I can already see significant improvements in my design work, which will help me in so many areas its worth spending the extra time on.

April is going to be a busy and exciting month I think.

The CircuitBee project is coming along nicely (major rethink going on right now…but thats a story for another post), but is still taking an inordinately long time to come to fruition. This gets really depressing after a while, so I’ve found that its great to take a break from my ‘big project’ to work on something smaller and short term to gain a bit of confidence and relieve the monotony a little.

So at the end of February I started work on what was supposed to be a small Android game. I quickly realised however that the work involved in making a whole game was rather large, so I’d need to break it down into steps that could be managed in a reasonable timeframe.

The original idea for the game was (and still is) called FallingMan, and involves a ragdoll man falling from the sky banging into things. This seemed like a simple project at first, but I soon discovered it was like every other software project out there – far more complicated than it first seemed. So as a halfway step to implementing the full game, I decided to create PinMan.

PinMan is a ragdoll stickfigure who you can shake around, throw at the wall, toss objects at and even pin to the wall with drawing pins (hence his name). This was a great little project to start off with, and it has given me most of the technology I need to create the FallingMan game.

We released PinMan on th 25th February, and saw about 3000 installs on the first weekend (Friday to Monday). This is for the free version of course, as the paid version picked up a very low number of installs. After the launch weekend the rate of installs fell back to a reasonable 300 new users per day. The free ad supported version has since ticked along at a slightly increasing rate of new installs, and is earning a few bucks a day through the advertisements. Not going to pay the bills or make me rich, but still, not bad for a halfway step to creating something else.

Since then I’ve made a couple more releases of the app, with some improved features for the paid and free versions, and put together a small website to showcase the app and a video of it in action. We now have almost 15,000 installs of the free version and are nearing 50 installs of the paid one. I’m quite pleased with this result for a couple of weeks work!

I’ve attached the video I made of the app below, making the video itself was an interesting experience which maybe I will recount some other day. I hope you enjoy it!