This month, I've been working on an avrdude app - an app that uses avrdude to program AVR microcontrollers. It's now finished, with 500 LOC in the app itself and 800 more in the associated libraries. You might be surprised - why this and not something else, like a messenger app? Here are the reasons:

• At the time, I had a small gig that involved programming 50 ATMega-based boards. So, after working with avrdude for quite a while, I was quite sick of it and wanted to automate it away - and also wanted to make sure there's a straightforward way to burn popular bootloaders to ATMega-based boards, which is a big part of this app. Now, I don't need to be summoned anywhere to program a new batch of boards - I can just give that person a ZPUI-enabled device with a user-friendly interface.
• ZPUI needed a helper class to run long-term processes and parse their output - which is something that avrdude app would need, so after I wrote it, it only made sense to write an app around it. Such a class will be necessary for anybody who would want to write a wrapper to run any command-line tool and see what it outputs in real-time - be it ffmpeg or mjpg-streamer (which I plan to add for single-click video streaming), an interactive CLI script that needs your password, another microcontroller flasher or just a long-winded script that you want to monitor, there's now a way to wrap it in a developer-friendly object you can use to get output, send output and terminate the process at a whim (surprisingly, something that I still haven't found a proper Python library for).
• I wanted to understand whether there's something that ZPUI lacks - it's something you can only see while you're programming a large app like this, and given that I'm the only person working on ZPUI and controlling its direction, it's crucial for me to check every once in a while if there's something that could be added to ZPUI. As a result of this work, I've added a lot of new functions, and more different ways to use the existing ones.
• Also, I wanted to test out the recent ZPUI additions - like context switching, canvas system and class-based apps, and write a large app that uses all these things in a way that others can then refer to. While I was writing this app, I uncovered plenty of bugs and inconsistencies, which were promptly fixed.
• Last but not least, writing large apps gives me the experience I can use to advise others on writing large apps - for now, nobody but me has this kind of experience, which is necessary to help people writing large apps that actually work.

The end result is an Atmel MCU programming app that can backup and restore firmware from/to the MCU, flash arbitrary .hex files and bootloaders. For now, I've only tested it with usbasp programmers, but linux SPI device and other programmer support will be coming soon. I've used it a lot already, and it's even more useful given that I'm now working on several AVR-powered ZeroPhone mod boards (so, a simple way for users to update the mod board firmware is needed). It also has pinout information and the most crucial settings available, as well as some user-friendliness related features. In addition to that, there's a lot of bugfixes, improvements, new ideas for improving ZPUI and insights into problems that ZPUI has.

One large problem that I now understand ZPUI has - lack of some kind of markup system for UI design. Essentially, when you're trying to draw your own UI, you need to calculate position of each element on the screen, requiring plenty of math (and extra variables) if you don't want parts of your UI to overlap/disappear. When it comes to text, the situation is even worse - as of now, it's pretty much impossible to properly word-wrap arbitrary text on a screen, for example. What do we do about it? I have no idea yet, and that's something I'll need to address sooner or later, unless I want ZeroPhone to be infamous for ugly apps... or not scaling further than the small display we're currently confined to.

There are also some problems regarding UI elements not being universal enough - for example, there's no way to have a Nokia-style settings menu (a menu with combined checkboxes, listboxes and sliders), combining lots of different settings in an easy-to-use view. Input UI elements still aren't any good, either, I expect to work on them once I get to the SMS-related apps, which will happen soon - I'm working on the modem integration with ofono now, continuing work that monsieur_h started. In general, I'm thinking about the UI a lot now - can't wait to make a proper main menu, with icons in a grid and everything!