Showing all entries for: July 2011
Take a look at Calvetica Calendar for iPhone. This app has a stunning, almost metro-like interface and I think is one of the best demonstrations of a custom iOS interface. It’s completely immersive, and seems to use no default-looking iOS controls.
I think these types of interfaces are what Corona developer’s in particular should be inspired by. Sure there are native-looking interface widgets rolling out, but they can be customized to use your own look-and-feel.
I heard of the Calvetica Calendar app via Ben Brooks’ Review.
How to Use XML Files in Corona. New tutorial I wrote on Ansca’s blog that’ll show you the easiest way to use XML files in your Corona projects.
What makes a good butler? I’ve never had one personally, but if I did, here’s a list of qualities I would look for:
He would be as transparent as possible, yet immediately available at a moment’s notice.
Once I’ve given him a task, he would work as quickly and as efficiently as possible without causing problems or extra friction in my workflow.
His purpose would be to free up time and reduce stress by carrying out all of the tasks that I never want to, but out of necessity, have to—ultimately leaving me with more time and mental clarity to get more done.
He would be smart. Over time, he’d learn to predict—to a certain extent—what I’m going to ask of him without me even having to finish.
Meet Alfred. He’s a butler who meets all the above qualities I described above, and he lives in your Mac. But unlike a real butler, Alfred is free.
Of course, I’m talking about the application launcher app by Running with Crayons.
This is my first—and only—venture into using an application launcher, so I really have nothing to compare my experience to, of course, except for working without one. But first, a little back-story of why I decided to give Alfred a shot.
Passive Peer Pressure
I’m a regular reader of The Brooks Review and ShawnBlanc.net. Both authors are big fans of LaunchBar—which is another application launcher, similar to Alfred. Every so often in their posts, they make a mention of the software, so naturally I got to thinking if something like that would be useful for me as well.
Also, constantly seeing Carlos and Walter—co-founders of Ansca—navigate source code files solely using the keyboard like nothing I’ve ever seen before in my life opened my eyes to just how much more productive I could be if I were to go as mouse-less as possible (another benefit to using application launchers).
And although I don’t hate using a mouse, I absolutely despise using trackpads (although I love two-finger scrolling with them). I don’t always have my Macbook Pro plugged into an external monitor and a mouse, so during those times, I’m stuck with the trackpad (arghhhh).
So the combination of constantly reading about others benefiting from application launchers, and seeing the benefits of using the mouse less started peaking my interest in using an application launcher.
Prior to all of that though, the thought of using an application launcher app didn’t really appeal much to me. I figured using a mouse to find an app, either in the Dock or the Applications folder, would be much easier than typing it out.
And for any other time that I did need to type to find something, the built-in Spotlight app sufficed (though I was admittedly annoyed by its laggy-ness, it didn’t even occur to me that an application launcher’s performance could be any better—I thought it had to do with OS X’s HFS+ filesystem and my non-SSD hard-drive).
And while I’m not afraid to try new things, I didn’t want to pay for an app that I didn’t feel like I needed that much (or might not be able to incorporate into my workflow). I would have tried QuickSilver (free), but I have this aversion to using abandonware.
And on TOP of all that, I’m very picky when it comes to the user interface of the apps I use, and frankly, LaunchBar just didn’t appeal to me. An application launcher would only be useful if I choose to use it regularly, but I know I won’t choose to use an app that I don’t like the look of, especially if I’m already used to using the alternative.
And then I discovered Alfred.
Alfred is an application launcher that’s very minimal in it’s design, but also very clean and Mac-like at the same time. After reading some positive reviews of it, I decided it was finally time to give an application launcher a shot.
All this talk of application launchers and I haven’t even described what it is. The name is pretty self-explanatory, but most application launchers do much more than just that. Normally, they can search for files, contents of files, scripts, etc.
Alfred (free version) does all of that and more:
- Quick web searches in your default browser.
- Can serve as a calculator.
- Get the definition of words quickly.
- Custom web searches.
- Perform system commands (e.g. “shutdown, restart, sleep, etc.”).
And if you purchase the PowerPack add-on, roughly $20 (USD) but highly recommended, you get:
- Built-in filesystem navigation.
- Perform actions with specific files, as well as search the contents of them.
- Start composing an email (e.g. “email email@example.com”).
- iTunes mini-player.
- Clipboard history and snippets (there are apps out there made only for this purpose).
- Quick access to your address book.
- Customize Alfred visually with color themes.
- Launch terminal commands (!!).
- Custom fall-back searches (search alternative websites when something is not found).
- Global hot-keys for apps and scripts (of course, I have one setup for the Corona Simulator).
- Sync settings via DropBox or iDisk (useful if you have multiple Macs).
- Probably something else I’m leaving out.
You get all of the above in a tiny, well-designed, elegant little window that can be activated with a simple keyboard shortcut (I replaced the Spotlight default, which is
Cmd + Space, but the Alfred default is
Option + Space).
Just looking at the feature list, you can already see that this app is far superior to Spotlight, and I’m sure that even if you’re not an application launcher type of person, you can still pinpoint at least a few items above that you have to admit would be nice to accomplish by typing a few letters into your keyboard.
Alfred is fast. It outperforms Spotlight by miles, and does way, way more. As soon as you press the keyboard shortcut to activate Alfred, there he is, ready to go. The moment you begin typing, Alfred is already fast at work, trying to predict what you’re looking for (remember the “smart” bit from earlier?).
I’m running a 2011 Core i5 13” MacBook Pro and I haven’t had any issues with speed whatsoever. I don’t think it’s lagged on me even for a brief moment, as Spotlight frequently did.
It’s not that difficult for these apps to be accurate at finding what you’re searching for, that is, IF you type the full name of what you’re looking for (which would be a pain). As I mentioned above, as soon as you start typing, Alfred begins showing results—without interrupting your typing flow.
For example, if you type the letter “i”, Alfred will list the apps that begin with the letter “i” instantly (unless you have a custom command set up specifically for just that letter), ordered from the most recently launched. The item at the top of the list can be activated by pressing return, and the others by either the up/down arrow keys, or with keyboard shortcuts (
Cmd + 2,
Cmd + 3, and so on).
The app behaves in this same manner, consistently, whether you are launching an app, opening a file, executing a system command, etc.
To launch an app, most of the time I only have to type the first letter or two and Alfred’s got it on a silver platter, ready for me to hit return and quickly launch it.
Alfred’s accuracy and speed has come in very handy several times since I’ve been using the app, and it really makes me wish I had ventured into application launchers sooner (or maybe not, because then I might’ve got used to something other than Alfred, which I am loving right now).
The first couple of days I had Alfred installed, I loved what it could do, but out of habit I kept doing things the old way. In the beginning, his “transparency” sometimes caused me to forget he was even there. At first I’d only remember about Alfred whenever I got frustrated with having trouble looking for an app in the Applications folder. Once that happened a few too many times, I started remembering Alfred more and more.
Now, since I’ve gotten used to using Alfred, I can’t stand the thought of navigating the Applications folder up and down searching for the app I want, or using Spotlight hoping it’ll give me fast results. Lion’s LaunchPad? Please. (Though I think it’s great for new Mac users).
My Dock is now hidden thanks to Alfred. I don’t ever need to use it as an application launcher anymore, now it’s just used for shortcuts to my Documents, Downloads, Trash, and currently open apps (which I’ve been using
Cmd + Tab to switch between).
3 Tips for Transitioning:
Here are my tips for making the transition to using Alfred over traditional application launching methods a little smoother:
Hide the Dock. This has been the single-most helpful thing I’ve done to speed up the transition to using Alfred. Out of sight, out of mind. Alfred will be easier to remember because most likely, your hand will already be on the keyboard.
Remove all of your apps from the dock (so only running apps show up there).
Use Alfred for everything you can think of (that it can currently do)—constantly. That’s the best way to form a habit, in this case, a positive one.
My Favorite Features
Application launching aside, here are my favorite features in Alfred 0.9.1:
The ability to start composing an email by simply typing “email [person’s name]”.
Being able to open files using the “open [filename]” command.
Easily “forcequit” an app by typing same into Alfred.
The fact that it’s core features are free (huge advantage, especially for newbies like me). I have the PowerPack, but if I just needed the basic core features, this would be one awesome freebie.
Being able to shutdown, restart, and put my Mac to sleep faster and more convenient than ever before.
The clipboard/snippet manager, which has saved me several times when I needed to go back and get something that I copied to the clipboard previously. Also useful for storing email signatures.
Being able to launch quick web searches without having to launch the browser first.
The fact that adding Spotlight comments to individual apps and files improves Alfred’s ability to find exactly what you’re looking for (this is awesome. You can even “nickname” specific apps and files if you want to by using Spotlight comments).
The in-line calculator. Good-bye Mac OS X Calculator app.
I haven’t encountered a single one, even though Alfred’s version is less than 1.0 (which implies beta, but I’m not so sure it is). Kudos to the Running with Crayons team for creating such a stellar app with very little to no bugs (as a developer myself, I’m hesitant to say no bugs, but this is about as close as it gets).
My Features Wishlist
With such a positive review, it’s hard to imagine any shortcomings this app has (it does so much, and does it all so well). This is especially true since I’m not coming from another application launcher where Alfred may not have every feature that other apps do (I wouldn’t know).
I do, however, wish I could do some things that I currently can’t in this version (hopefully for me, Running with Crayons is listening, heheh).
Quick Reference Popup:
While I was still trying to get in the habit of using Alfred on a regular basis, I kept constantly wishing there was a separate keyboard shortcut that would open up a separate popup over on the side, similar in appearance to the main Alfred popup, which listed all of the available commands (including custom).
For example, a few times I forgot whether the command was “close” or “quit”, so I’d try one and hope for the best. Or, I’d have to go into the Alfred preferences and look it up myself (which takes way too much time). I guess I should’ve known, but hey, it happened. That’s just one example (hey, everyone has a brain fart now and again).
Another thing a popup like this would be useful for is a reference for keyboard shortcuts, because those are the hardest to remember. Having a quick reference that’s just as available as our trusted butler friend would help with the memorization of these shortcuts by a great deal. Even as a regular Alfred user now, this would still be extremely handy for me.
With the PowerPack (which I have), I love the ability to quickly enter a terminal command and have it quickly popup. This feature request is a little nit-picky, but I think it would be very handy if a little terminal, in the same style as the Alfred popup itself, expanded beneath the text field and allowed you to work from the built-in terminal instead.
Hey, there’s a built-in filesystem browser, seems like the idea of a built-in terminal doesn’t sound too far-fetched.
Secure Password Manager:
Bear with me here. I usually use LastPass (which is a free alternative to 1Password) for generating and storing secure passwords for websites (etc.) and easily filling them out automatically upon visiting the websites.
This approach, however, requires that a special plugin be installed—and actually be available—for my browser of choice. Form filling also only works for websites, so if you need a password in an app, you have to retrieve the password from LastPass first. Unfortunately, the plugins differ from browser to browser, and frankly, that’s pretty annoying.
If only Alfred had a secure password manager, generator, and form-filler built-in, it could not only store any secure password I needed (or generate new ones), but I could also use it with whatever I wanted (whether it’s a browser, app, etc) by using a simple command such as “fill” or something similar. I could then, of course, stop using LastPass.
Of course, Alfred would have to somehow know when to ask for your master password (or it would defeat the purpose of having a password), but it could work similar to how iTunes does, where it’ll ask you for the master password after a certain amount of time has passed (and have this be configurable).
I know it’s a bit far out there, but Alfred has things like the clipboard manager, which is so well-implemented that it eliminates the need for another app to serve that purpose, so I’m curious to see what Alfred’s implementation of a secure password manager and form filler would be like.
And don’t quote me on this, but I don’t think any other application launchers have this feature, so if included, would be a great feature to set Alfred apart from the competition.
So apart from having to train myself to get in the habit of actually using the app, Alfred has proven to me that application launchers are totally worth it. And it’s so good, I don’t even have the desire to try the other ones.
Alfred has simplified my computing by handling the simple, mundane tasks that would often become the source of unnecessary friction, and ultimately disrupt my workflow. Like a good butler, Alfred has enabled me to be more productive, and focus on doing the things that really matter—instead of all the little chores in between.
On top of that, I’m able to use my mouse less, which means I can use my trackpad less—which is a huge benefit to me. Great job, Running with Crayons—I’m sold. I can’t wait to see the next version.
And as a side note: Alfred, with it’s elegantly minimal design and infinitely useful functionality, is the type of app that makes me—as a developer—want to start creating some Mac OS X apps, instead of being a mobile-only developer.
Open Source Corona Puzzle Game. Description from the page:
This sample code is a demonstration of how you could implement a simple jigsaw puzzle concept using the Corona SDK’s bitmap masking functionality.
I created this a long time ago and it was just sitting on my harddrive, so I thought I’d put it to good use and share it with the developer community.
It is optimized for Galaxy Tab/Nook dimensions, but could of course be tweaked to match any dimensions. It’s the logic you care about anyway!
Download to learn from it, or use the code in your own projects.
New iPhone 5 Case Designs?. If the image shown is legitimate, or really does represent an upcoming iOS device, I think it’s more likely to be the new iPhone-lite (e.g. iPod touch + no contract phone) than an iPhone. The design of the iPhone 4 is just too elegant for them to completely scrap after a little over a year, in my opinion.
But, you never know…. the original iPhone body was scrapped after just a year, but that’s almost to be expected with a first generation device…. of it’s kind.
Great Call by Mike Elgan from 2010. Mike Elgan wasn’t afraid to share his opinion in 2010 before the iPad launched, went out on record and said the iPad would be a big deal. No ifs, ands, or buts about it. He didn’t say it would do good, or he thinks a lot of people would like it.
He flat out said it would be HUGE… and he was spot on:
I know I’m going to catch a lot of flak for this column. I’ll be accused of being an Apple fanboy, and worse. I will be told that netbooks are better, or Windows- or Linux-based tablets will do better. I’ll be told that iPad will just be a niche product of little significance.
My answer: Wanna bet? If so, get an iPad.
I know it’s an old piece and largely irrelevant right now (duh-material), but the article from Mike Elgan earlier made me go digging for more. I know I’m late, but great call, Mike.
On a side note, apart from my father, I’m probably the only tech “enthusiast” in my family (e.g. nerd). And guess what? My wife has an iPad/iPhone, my mom has an iPad/iPhone, my brother has an iPad/iPhone, even my mother-in-law has an iPad/iPhone. And here’s the kicker: They all use them on a regular, daily basis—and they’re not nerds. This thing is HUGE.
UPDATE: The comments thread on the article is hilarious in the context of today.
Windows Magazine Editor Converts to Mac. Mike Elgan, hardcore Windows user, switches to Mac OS X:
I’m an Apple fanboy. Once you hear my story, you’ll agree that if it can happen to me, it can happen to anyone.
(via Marco Arment)
Underwater BBEdit Color Scheme. Reader JP Lew saw my BBColor Scheme post and sent me his color scheme. It’s a very nice theme and easy on the eyes as well.
It’s his BBEdit port of a popular Vim theme. You can get the original Vim theme here.
Diary of a TouchPad Owner. Shawn Blanc outlines his experience with HP’s Touchpad, from before purchase all the way through extensive use. The gist is that the HP has it’s areas where it shines, but as of right now, they are few and far between. It sounds like he really gave it a shot, and it’s just lacking in way too many ways.
I still have hope for it’s future though—not as a “winner” over the iPad per say, but at least as a worthy competitor in the tablet space. The iPad needs a better competitor than Android/HoneyComb tablets that have been coming out, and I think if HP tightens up the loose screws, the TouchPad (2 perhaps?) may be it.
Shawn’s previous review of the TouchPad, along with this public diary he just published today may sound harsh, but it’s great feedback for HP—an honest account from an end-user of their product. From what I’ve heard, HP seems to be handling constructive criticism very well and will probably do something about it, unlike RIM, who seems to have given up on the PlayBook after their huge miss (I say that because I have not heard much of anything about it since the initial—horrible—reviews came through).
I love the Corona SDK—everyone knows that. But at the moment, it only does (and excels tremendously at) cross-platform mobile apps.
Sometimes though, I get the urge to make native software for the Mac, but I just can’t get used to anything other than the high-level, super-fast development approach that Corona takes by using the Lua scripting language for development. I absolutely love programming in Lua because of its easy-to-understand syntax, its flexibility, and how quickly you can go from zero-to-app in no time flat when using it in conjunction with Corona.
Because Corona has spoiled me so much, I really can’t (due to time constraints)—and don’t want to—learn Objective-C just to make Mac OS X apps. I’ve been spoiled rotten with simple Lua syntax, and the fast development speeds with Corona to even go near there.
And since there really isn’t a Corona-equivalent for desktop apps, I just figured it’s not my time to make anything for Mac OS X just yet—that is, unless Corona supports it as a target platform at some point. However, I did come across something earlier… and it’s not quite Corona-for-desktop per say, but it is an official solution to desktop apps (non-game apps, at least).
It’s called AppleScriptObjC, and I’m surprised I haven’t heard of it before (it’s been available since Snow Leopard).
I don’t know too much about AppleScript or it’s history, but some quick digging and I discovered that originally, AppleScript was used to “script” the Mac and other apps in various ways (duh). Then, Apple came out with something called AppleScript Studio (ASS; shipped as part of Xcode in 10.2) which allowed developers to use AppleScript to make full-fledged Mac apps. Sounds awesome right? Well it gets better.
Since AppleScript Studio required maintaining a branch separate from their primary Objective-C (documentation, API’s, etc), in Mac OS X 10.6 they deprecated ASS and replaced it with AppleScriptObjC, which serves the same purpose, but is much more “compatible” with Objective-C than its predecessor, yet from the looks of it, still vastly easier to use. And here’s the kicker: It’s been included with Xcode since Mac OS X 10.6. So if you’re a Mac or iOS developer, then you already have it.
After more Googling, I also discovered that surprisingly, there’s not a lot of literature on AppleScriptObjC. I did manage to find a quick AppleScriptObjC tutorial on MacScripter which seems to leave out a little too much for a complete understanding, for those like myself, who know neither Objective-C nor AppleScript. However, if you take a moment to go through the tutorial, you start seeing just how vastly intuitive AppleScriptObjC is over vanilla Objective-C.
Apple’s official page for AppleScriptObjC says you need to know Cocoa (e.g. Objective-C) before using AppleScriptObjC, but doing some poking around you can see that there are plenty of AppleScript developers who don’t know Objective-C and are getting along just fine with AppleScriptObjC.
John Welch, an AppleScript developer who doesn’t know Objective-C began using AppleScriptObjC is one of them (emphasis mine):
In one sense, my refusal to deal with the unending limitations of ASS have been a help, as I don’t have any bad habits to break from that direction. Since I don’t know Objective C, I don’t have to deal with those differences either. However, the lack of ObjC knowledge is a bit of a pain in the keister when reading Apple developer docs, although not as much as I thought it might be, thanks to Craig’s tutorials.
Judging by his experiences, personally I think Apple says you need to know Cocoa so they don’t have to dedicate too many resources to the AppleScriptObjC documentation (because if you know Cocoa/Objective-C, then the documentation they have now should be sufficient).
Thankfully, there’s a solution for those who don’t know Objective-C or AppleScript. It’s called AppleScriptObjC Explored by Shane Stanley ($29.95, eBook format), and from the looks of it, this book seems like a great A-Z resource for learning how to develop real Mac apps using AppleScriptObjC. Take a look at the table of content screenshots and see for yourself.
AppleScriptObjC looks like a great solution for those who want to make (non-game) native Mac apps without having to learn Objective-C. If you don’t know AppleScript, you’ll have to learn something, but at least the learning curve isn’t as great. From my initial observations, the learning curve seems slightly greater than that of Lua, but not by too much.
Another big plus is that you can use Xcode’s amazing Interface Builder when creating your AppleScriptObjC apps, to the extent you can with normal Cocoa apps. Very, very awesome.
For those that do know Objective-C, it looks like you’re free to use whatever library you want. In fact, there seems to be no real limitations since it’s so closely integrated with Xcode and the rest of Apple’s API’s (but I’m not so sure about the level of visual customization/theming your apps can have, and OpenGL games seem to be out of the question). Don’t quote me on any of that though, because I have zero experience with it at this point—definitely do your own research if any of this sounds interesting to you.
The main drawback to this of course, is that you can only develop Mac OS X (10.6+) applications using AppleScriptObjC, so cross-platform is out of the question. There are tons of successful Mac-only developers out there though (e.g. Bare Bones Software and Panic, to name a couple), so this definitely isn’t a downside for everyone.
Another bummer is that if you don’t know Objective-C or AppleScript, you’ll most likely—at the moment—have to fork over some cash to buy the AppleScriptObjC Explored eBook that was mentioned earlier. You may want to do this anyway, even if you do know said languages.
So as it stands, if you want to make some software for the Mac but want to stay as high-level as possible when it comes to development, then I’d say the upsides far outweigh the downsides and you should definitely buy Shane’s book and dive right in.
BUT, if Corona ever supports Mac OS X as a target platform, then I’m sure you already know it’s gonna be Corona SDK all the way for me (as it already is in the mobile space).
You may have seen the reports yesterday, but in case you missed it, patent troll Lodsys added several others to their mobile gaming patent lawsuit. More on that in a moment, but first, let’s re-cap on what this Lodsys thing is all about.
Lodsys LLC has stepped into the spotlight fairly recently for targeting small iOS developers (who don’t have the resources for a legal battle) for allegedly infringing on a patent that they hold. The patent has to do with in-app upgrade buttons (seriously), and they gave developers two options: pay a license fee, or get sued. A pretty grim scenario there.
Thankfully, Apple stepped in and wrote a letter to Lodsys. The letter basically states that since Apple is licensed, so are their developers, since developers aren’t actually selling anything—Apple is.
That makes a lot of sense when you think about it. If you make a “sale” of one of your apps, you’re not actually making a sale, Apple is—they are simply paying you a hefty commission for it (70%). What I think it boils down to is this: Apple owns the store, Apple is processing the payments, Apple is distributing the apps, Apple handles customer support, and they also cut the royalty checks. It’s clearly all Apple (aside from the actual development of the app), so if Apple is licensed, so should developers of their App Store be.
Of course, the final word is up to the judge, but I think Apple makes a pretty strong case in their letter. However, since Apple doesn’t own the app (the developer does) one could argue that a developer could infringe on a software patent separately from Apple, despite the rest. But since all the in-app upgrades are just more sales within Apple’s own App Store, you can then argue back that it’s all still under Apple’s umbrella (e.g. license).
The whole thing could literally go back and forth forever (I guess that’s why it’s likely going to court).
Should you be scared?
If you’re an iOS developer, the obvious question would be, am I next? Should I be scared?
I don’t think so. And here’s why…
Among the “several others” Lodsys recently added to the patent lawsuit include: EA, Atari, Square Enix, Take-Two Interactive, and Rovio. Surely they did this because they are confident that they have a very strong case, but in all actually, they just shot themselves in the foot (IMHO).
Before, if Apple was—for whatever reason—unable to participate in the lawsuit, then the developers that Lodsys originally targeted would be screwed. Small developers simply do not have the resources to fight a patent lawsuit on their own, and some of the Lodsys “victims” have even expressed it.
However, Lodsys just picked on the biggest players in the App Store now. Companies who are much bigger than Lodsys and surely have the legal resources to fight (and win) this lawsuit. This is great news for developers, because if Lodsys loses, it’ll make it even harder for patent trolls to do the same thing Lodsys tried to do.
Of course, I’m getting ahead of myself here, because nothing has actually went to court and been settled here… but I think it’s obvious where things are headed now.
Making Things Up (Macalope). One of my favorite MacWorld columns is The Macalope Weekly. This week he’s poking fun at Dan Gillmor on leaving the Mac, jail-breaking, and Eric Schmidt.
Is Android the Wiser Investment?. That’s the question in today’s first “Friday Night Forum” run by Hetal at Ansca (post your response in the comments section).
Personally, I don’t think Android is the wiser investment. I think maybe due to it’s fast growth in the smart phone area, that may attract more jobs in anticipation for Android to be great. But from the looks of it, I think Android in the long-term is going to be pushed further and further into the low end (kinda where “feature phones” are right now, and how well is Symbian—aka, the “former king”—doing now?).
My reason for thinking isn’t just because Android is struggling in the tablet market, because that doesn’t mean it can’t continue to do well in the smart phone arena, but because it seems more and more that the major Android players are going to start venturing off with their own platforms (e.g. Motorola, Samsung, maybe others?), instead of piggybacking on the “me too” Android phone race.
I mean it makes sense doesn’t it? Who wouldn’t want their own identity?
On top of that, I’ve also heard Google is a bit of a pain to deal with when it comes to this awesomely “open” Android (and only stands to get worse if all these Android lawsuits don’t go in their favor).
Corona API Reference Easy Access. This is a simple app that does one thing: open a window with a web view pointing directly to the Corona API Reference page. Since it’s just a web view, it’s always up-to-date.
I made it (using Fluid) so I can have quick access to the API’s from my Mac OS X dock:
From my understanding, you can also make an app like this yourself using Automator in Lion, but I decided to go the Fluid route.
P.S. The cool looking icon was Biffy’s Corona icon submission from a while back :–)
AT&T Still Beating Verizon with iPhone. Brad Reed, reporting for Macworld:
If Verizon thought it could swoop in and take AT&T’s iPhone market share overnight, it thought wrong. In the recent quarter, AT&T reported activating 3.6 million iPhones, roughly 56 percent greater than the 2.3 million iPhones activated by Verizon in the same three-month period.
I think most Verizon subscribers who didn’t get the iPhone4 when it came out really had no reason to switch during this past quarter (except for maybe those who were due for an upgrade).
Perhaps the rest of the Android or feature phone-wielding Verizon subscribers who want to switch are just waiting until iPhone5 ships this fall.
For those wondering how I “roll” when it comes to coding, here’s my color scheme for use with BBEdit). After lots of tweaking, coding, etc. I found this color scheme to be perfect for me. It’s called “Beebe Dark”.
For BBEdit 10 users (just released, and is amazing):
- Download Beebe Dark.
- Close BBEdit (if it’s currently running).
- Drop the bbcolors file into:
~/Library/Application Support/BBEdit/Color Schemes/
- Re-open BBEdit, go to Preferences, Text Colors, and select it from the Color Schemes drop down.
For BBEdit 9 and/or TextWrangler users:
- Download Beebe Dark.
- Download and install BBColors.
- Close out of BBEdit/TextWrangler.
- Drop the bbcolors file into:
- Follow the BBColors instructions on how to load the color scheme.
If you’re not using the newly released BBEdit 10, either upgrade now or purchase it because it is (in my opinion) the best text editor for use with the Corona SDK.
Update: Earlier this morning, I changed the color scheme of my website to match the color scheme of my code—so far I’m liking it. If it’s hard on your eyes, I recommend you subscribe to my RSS feed.
Update 2: I’ve discovered that this color scheme really only looks good with Monaco font, size 10 in BBEdit 10. With any other font I’ve tested, the colors seem a little too dull.
I know I haven’t posted here for a while, so I’ve decided there needs to be some changes.
The reason why I’ve stopped posting to my blog recently is due to the fact that I’m now a regular tutorial-writer on the Official Ansca Blog, so the things I’d normally post here have been ending up there instead.
The tutorials are pretty in-depth (probably more-so than the tutorials I normally posted here), so if you want to read the things I’ve posted to the Ansca blog so far (not just tutorials, but also my Daily Build feature announcements), you can go to my author page. Or, to view a complete listing of all tutorials posted to the blog, visit the Tutorials category page.
I love writing the tutorials there, that’s where they belong (there’s also a lot of great discussion in the comments section of each article as well—something you couldn’t get here). However, I don’t want to let this site go. Therefore, I’m going to shift my posts to more of a tech-centric, linked-list blog, more akin to the likes of my personal favorites:
I still plan on writing long articles, but most likely all of my Corona-related tutorials are going on Ansca’s blog—and rightfully so. It’ll probably take me a while to get into a regular posting schedule, so expect my post-frequency to remain low and ramp up gradually (at least I hope that’s how it’ll go).
Here’s to the future.