ooh gradients!

I should have written this yesterday, but some of you might have noticed that there is a new Canary beta out. If you don\’t have an earlier version of Canary, you can get it here: http://www.canaryapp.com/beta/Canary.zip

The UX is greatly enhanced and there are some new features like InstaFilters, proper filters (with boolean conditions etc.), full Growl support and more!  This is the full changelog:

• Authentication issue has been fixed.
• Added more delicious graphics.
• Support for eight kinds of URL shorteners with single credentials supported for each one.
• Optional automatic (on paste) URL shortening.
• Hashtag recognition and resolution (search.twitter.com).
• Added InstaFilters and custom filters.
• Recognizes and resolves IETF RFC and NBN.
• DOI, HDL, ISBN and ISSN recognition and resolution.
• Asynchronous adding/removing, blocking/unblocking of users.
• Growl notifications: Notifications appear only for new updates, new replies and new DMs.
• Growl notifications: When Growl notifications are clicked, the user is directed to the relevant timeline and message.
• Growl notifications: Sender/recipient names are switched according to the user selections in view options.
• Growl notifications: Various bug fixes and improvements.
• Lock icon shown for protected updates.
• Added switching between usernames and screen names in the view.
• Enabled text editing functions in the status text field.
• Retweeting functionality improved (does not send retweets immediately).
• TwitPic image transfers are now asynchronous.
• Temporarily disabled keyboard shortcuts for the status menu and status selection.
• Fixes for URL recognition.
• Limited the number and options shown in the timeline.
• Added support for more HTML entities.
• Character counter more accurate for direct messages.
• Added the count parameter in many API calls to resolve an issue with the retrieval of older updates.
• Other bug fixes and improvements…

This has led them to stop accepting GIF images for such uses and keep with PNG and JPEG images, at least for the time being.

Security has always been a major developer concern with regards to Twitter and there have been several requests for OAuth. The latest announcement means that the last couple of security breaches have sped up the process of OAuth deployment.

The negative side of this is that developers will have to make several changes to their code in order to adopt OAuth and users will have to cope with bugs that (inevitably) don’t get address the first time round (in the newest version).

I’m currently in the process of fixing some of the bugs already reported and thinking about implementing some new features. Any feedback, whether it’s a bug or a feature request or a user interface improvement or whatever, is welcome.

I’ve been talking about my little Twitter client for a while now. My aim is to make it as user-friendly as possible, without compromises in terms of stability and security.

I’m going to write several posts about the features of Canary both obvious and hidden and some of its internals, for those who which to know a bit more about developing on the Mac, especially those who are new to it.

Key features

- Supports multiple accounts, single click login
- See your friends timeline, replies, favorites, direct messages, archive and the public timeline. 
- Native Cocoa application, less memory and disk footprint, more stability
- Secure: uses https for getting and posting data, passwords are stored securely in the keychain, digitally signed application binary
- Post tweets, multiple tweets and retweets 
- One click replies to tweets and direct messages
- Fast URL shortening (⌘-S) with an option of five shortening services. 
- Upload images to Twitpic with drag-n-drop, post images from iSight
- Plus: add/remove, block/unblock friends, go to user’s home page (click on her image) and twitter page.
- Supports Growl notifications
- Automatic updates using the Sparkle framework
- Retrieve all updates since last execution*

* This number is limited by the Twitter API and the Canary user settings (number of updates shown).

Canary icon (designed by One Toad Design)

Well, it was about time. I’ve got a private beta ready for testing by any willing victims volunteers. If you want to participate in the beta testing phase, email/DM me or leave a comment below. I have invited all those that expressed interest before.

I will write about the features (obvious and hidden) Canary in an upcoming post and a tentative roadmap about what’s yet to come.

It is still a work in progress, but progress is kind of slow, due to my new job. I can spend relatively little time and it’s not really the most productive of its kind.

Still, I’ve managed to implement significant parts of the API (which I intend to release for free,  eventually) and some marginal improvements and additions to the user interface. More about the API implementation in a later post.

Here is a screenshot: 

Canary screenshot (latest iteration)

Bear in mind that, object-oriented development is not easy and you need more than knowledge of the language to develop software properly. I recommend starting by learning about object-oriented design before getting into Objective-C (or any other OO programming language, for that matter).

P.S. The tutorial covers parts of Objective-C 2.0.

Many of you may know C or may have heard of this particular tutorial. It is called “Learn C” and is written by Scott Stevenson (aka Theocacao).

This tutorial is geared towards those who have limited familiarity with programming and is a fast introduction to those interested in learning the basics before delving into Objective-C and Cocoa. It is one of the best around the web for C and if you want to start learning it is the best place to start.

Learn C: http://cocoadevcentral.com/articles/000081.php

I decided to look into things and find out more about the Twitter API and whether it would be easy (and fun) to work with it. I made a small client called “Canary”. It isn’t ready yet but it looks promising. It also proves that Cocoa development is extremely efficient, because it only took me about a day (it’s not a very complex app…).

Here are a couple of screenshots, to give you an idea of what it looks like so far:

You can read Fred Vogelstein’s Wired article here.

Read it here.

On the contrary, Windows applications (especially older ones) tend to spread out on your system, putting stuff everywhere but mostly to the registry. Uninstallers often remove only the original executable files, leaving behind all the registry keys that were created. Thus, registry files tend to grow larger over time, leading to slower systems and even corruptions.

There are certain Mac apps that tend to follow a similar pattern, adding files and spawning daemons but without providing a viable means of uninstallation. There are certain places you can check to make sure that nothing is left behind, littering or slowing your system down:

1. Mentioned previously, your user preferences (or defaults, if you prefer) are saved in a file with a name looking something like com.developer.app.plist in your Home/Library/Preferences.
2. Your global preferences are saved in a file with the same name in StartupDisk/Library/Preferences.
3. If the application has a pane in system preferences it is most likely located in StartupDisk/Library/PreferencePanes or Home/Library/PreferencePanes. If the application is really obnoxious, you can check StartupDisk/System/Library/PreferencePanes, where all the standard preference panes lie out of sight.
4. To make sure that the application doesn’t try to start itself automatically when you log in, make sure that the application (or a helper app) is not listed in the Login Items -> Accounts in System Preferences.
5. In addition to that, you can check that there aren’t any leftovers at StartupDisk/Library/LaunchDeamons or StartupDisk/System/Library/LaunchDeamons.
6. Many complex apps make use of StartupDisk/Library/Application Support and Home/Library/Application Support for additional resources, templates, presets etc…

I think this was in the Leopard betas as well, I just didn’t expect it to remain in the final version. The credits go to David R. Perek.

[via Cult of Mac]

[via Fake Steve]

No word about the upcoming native iPhone SDK.

Mac developers rejoice! The way I see it, the Mac dev community will gain significantly from this. Assuming Apple releases the SDK only for Xcode (Mac only, that is), it will be easy for developers to make the transition with little fuss. We are going to see many great Mac apps become available for the iPhone in little time. Windows-based application developers will have to make the switch or stay out of the game. Those who make the switch will find it hard to catch up.

Java is dead. I used to be an avid supporter of Java, mainly due to its platform interoperability. Mobile Java (Java ME) took off fast as it was considered to be the panacea for multiple mobile phone development. In reality, however, Java suffers from the disparity of the phones it is capable of running on. Developing Java apps is extremely troublesome due to the fact that the lowest common denominator of Java functionality across the market is very small (this, I think is mainly the vendors’ fault). It is almost impossible to make a complex Java app that runs (in comparable platforms) in the same way. On the contrary, writing native iPhone apps is beneficial because of its popularity and its uniformity. It is a platform with exactly the same characteristics provided to all its users¹. I expect that many Java developers will move on to the iPhone, thus maybe even causing mobile Java’s demise, earlier than expected.

Nokia is a mess. They deserve special mention as they have been hard at work undoing their own success. Each month there is a new Nokia SDK. There used to be Java and C++, then they added Open C (eh?) and very recently Maemo. They have about 4 million additional SDKs and variations on their operating platform (S80, S60 5th ed, S60 4th ed, S40, etc.). I expect that many of those disillusioned by the foggy landscape of Nokia-land (and uncertain roadmaps), will move on to iPhone’s greener pastures.

Windows Mobile and brand-specific development It is uncertain where Windows Mobile (or any other brand-specific development community) will be affected as much. Windows Mobile is not a dominant player in the market, has a loyal following and is supported by better tools (Visual Studio). Brand-specific development (excluding Nokia) is minimal, as it was eclipsed by Java and the advantages that it seemed to offer.

¹ Well, that is until Apple decides to come with 4 new drastically different iPhone models.

According to an article by Jocker that surfaced in ThesMac, our favorite company is working on a multi-touch PDA prototype with an iPhone form factor. Its operating system is based on OS X and sports a Finder-like interface (with files and folders), touch-based drag-and-drop and even a Trash can. The prototype also comes with mini-versions of iLife and iWork and (obviously) WiFi connectivity. The PDA appears to take advantage of the latest touchscreen interface patents, that Apple submitted during the past few months.

Apple (according to the same sources) is also working on another prototype: a slim laptop, about the size of an A5 sheet, based on the new iMac aluminum-glass design. This design does not have an optical drive. Instead, it features a new type of dock connector (that seems to be used with a dock station).

[via ThesMac (in greek)]