Making of Twitica Mobile for Android pt.1

I just finished the authorization system of Twitica Mobile so I think I should write this down.

I want to create Twitica Mobile, because I think my own client would looks cool on my phone. (No more reasons) So I spent few hours getting [PhoneGap](, which is a framework for HTML based phone applications to work correctly. After that, I draw the UI on my notebook. Few weeks passed and I started working on the code.

Of course, I use the same practice to create the mobile version by drawing the interfaces first. PhoneGap’s nature of being HTML allow me to test with Google Chrome before compile it to the device. (I hate Android emulator because it is very slow) Then, I asked Twitter for XAuth permission. (Actually, OAuth would just enough but the interface is not so user friendly when compared to other mobile clients) I got it approved in 3 days after sending screenshot of Twitica Desktop.

Of course the next to be done is coding. I start with the authentication system. Luckily, I’ve implemented XAuth before in Twitica Desktop, so I just copy and paste the code. To make the code clean, I split the Twitter framework to be in seperated file, and it also use OOP system. However, JavaScript’s nature is asynchronous and I found that when the token is received I cannot save it in the Twitter object. Again, I’ve found solution in this problem when coding Twitica Mobile for webOS so I copied part of [Prototype]( and use the bind() function to create closure. (Note that in jQuery, bind() is to add an event handler while Prototype’s bind() is to create closure) After few debugging, my app can login and save the token correctly.

The next part is the tweet display. Because I’ve created twitter framework I just fire it to load the home_timeline like ordinary XHR request.

Latest version's screenshot

*Twitica Mobile (PhoneGap) is open source, you can fork it at [](*

Making of Twiticas

Back then, there was a Twitter client by @dtinth that I love it use named thaiWitter (previously theDtTvB’s Twitter client). It have many great features and the developer is responsive to feature requests. Last year I requested timeline merging ability to be added, but I think it might never be implemented due to how complex it is so I ask the developer for permission to fork. He allow me to fork the client side code, and implement the server side myself. I named the project “thaiNica”. It would download thaiWitter, patch it up and output to a file. However, due to the design of thaiWitter timeline do not load after second refresh and so on. I have stopped working on thaiNica for some time.

Few months later while summer is approaching, I realized that Twitter is full of non-geeks and blogged in [my blog]( that I would make a client that can read both timeline at once.

I decided to use Chrome, because I think it’s the browser that have delivered most HTML5 features. Also, it have “Create web application” feature so end users can make it appear in box like thaiWitter more easily. (@dtinth told me that his decision to use Mozilla Prism is that Chrome’s handling of Thai language isn’t perfect at that time.)

First, I started by copying thaiWitter’s interface. I created all the markups myself and almost all shades of grey I guessed the color myself. After the basic interface is in place, I started on working with its notification system.

Twitica (the “Desktop” was added later, read on) have two types of notification. The first one that got implemented first is in-app notification. I use the design from [notify-osd]( instead of thaiWitter’s square layout because I think it’s not interesting enough. Also, I added hover to reduce opacity system like in Ubuntu. It was just few more lines of CSS with no JavaScript involved. The next stop is to make it appear programmatically. I added notify() function, which as of now haven’t been changed ever since Twitica started. It would add the notify and animate it using WebKit’s CSS transition. Benchmarks show that with hundreds of notifications active, Twitica still runs with almost no lag while thaiWitter with JavaScript animations lag easier. (Mozilla Prism do not support css transition yet)

The next one is desktop notificationwhich is also still intact since I started. It mainly use [Chrome notification]( that have been developed with the Chrome OS. Also it works with Prism and Fluid but haven’t tested yet.

After that I begin adding timeline loading codes and rendering. I used basic auth and write the framework myself using OOP. I then make API for identica too. However, injecting tweet in between the timeline is hard, so I didn’t implement timeline merging anyway.

Luckily, identica have new feature that I just know of and it is being used in the website: the Realtime plugin. So I use varnish to proxy to identica’s meteor server and timeline just loads in realtime. (Althrough it have like 4s lag) This make timeline merging quite not nessesary.

After basic usage worked, I begin adding advanced features. Starting with geolocation with Google Gears because I saw that identica’s homepage also provide this feature, and then media upload.

Few weeks passed, and the first Chirp conference have the user stream introduced. I think “omg I must be the first to implement this”, too bad they allow the people who attended the event only to use the stream so TweetDeck and Echofon done that before. (At this time of writing they’re doing close-beta test) After few days it is available for public but under disclaimer that I couldn’t distribute the product. I decided to implement it and some more hacks later it was working.

Strangely, after the stream was added, CPU usage reached 100% for all time. I started optimization project and changed how Twitica scroll the timeline to make it more efficient, disable some effects like background image and the biggest (but mostly not noticable) is to move user stream handler to web worker. (However, Twitica Desktop nowadays have a rare bug that mysteriously make entire OS slow to crawl and probably occur in Linux too. I couldn’t trace the source of this bug because the machine is too slow to debug and it not easily reproducable. If you’re victim to this bug just close Twitica Desktop and in 3secs your computer will return to normal speed)

After I passed Triumudom Suksa entrance exam, I got the [Nexus One]( I tried Twitica on it and found that it works, even web workers is working. So I decided to tweak some around as described in my [old post]( to make it usable in the N1.

While Twitica use Basic Auth, its use have been deprecated for some time. Finally, Twitter put a deadline to shut the Basic Auth. This requires me to use OAuth instead. Still, I think it would be better to use XAuth (can’t remember why, besides it easier to implement) so I requested XAuth and got approved a week later. I got XAuth implemented in few days. When the deadline is approaching near, Twitter announced that there’re many failwhales making migration of some clients hard. They decided to move the deadline to August instead 🙁

While registering to OAuth, I found that “Twitica” have been used. I have to change to other name, but I already have Twitica Mobile (will write about that later) so I decide to name the web version “Twitica Desktop”.

When Twitica Desktop was fairly in place, and I haven’t got the Nexus One yet, I was fanatic of Palm webOS. (and it continues to nowadays) So I decided to make Twitica Mobile in case I got the Palm Pre Plus. (Sadly, the AT&T version doesn’t have 2.1GHz 3G so I bought the N1 instead) It use Basic Auth too, but it have real timeline merging (without keeping message between refreshes, and no stream as it would drain your battery) It have as much features as the Desktop version (Geolocation, Native RT)

**Next entry:** Twitica Mobile on PhoneGap and Twitica DS (formerly DSTwitt)