… for $3.99. Whilst providing a desktop build for free, and source downloads at the bottom of the product page which apparently this fellow feels meet the terms of the GPLv2 sufficiently.

We say “apparently”, because there is a body of opinion out there that since the casual consumer cannot edit the source code to an App Store-bought application and run the edited program directly on their phone, it is impossible to comply with the terms of the GPL with an application distributed through the App Store. We don’t subscribe to that personally, mind you; first off, nowhere in GPLv2 does it explicitly state that you must be able to run it on the distributed device — so being able to run your modified code in the simulator, which requires nothing but the freely downloadable Xcode toolchain, arguably satisfies the license adequately. And even if you do insist that the terms implicitly require that you run the modified version on the distributed device, then we don’t think that the $99/year developer program fee to Apple to be able to run whatever source you like on your phone is a condition that amounts to a GPL violation, any more than needing to buy a commercial compiler to do something useful with any desktop GPL’d source would violate it. But as the Free Software community is disproportionately populated with Apple-haters, mere logic is not always sufficient to appease them; and as this (to our knowledge) is the first GPL-licensed iPhone program that anyone has attempted to charge money for, if there is anyone out there willing to test their anti-iPhone interpretation of the GPL in court, well, this is whom they’d probably pick for a test case.

So we’ll be watching to see if any of the huffers and puffers get all indignant about this fellow’s entrepreneurial bent; and if not, we’ll probably look for some GPL’d game to port ourselves, as we would rather like to have an open source iPhone project to direct those who would like to see some demonstration of our coding practices to, and hey if it might make a buck or two that’s always great as well! In the meantime, if you’re a desktop Tux Racer fan, and not a programmer yourself — buy it to encourage more GPL’d source ports!

Colophon:Well, today was to be the final client-provided post of The Great WordPress Client Test, finishing up with über-text-editor

TextMate 1.5.8!

but the actual testing ends up a DNF, as we couldn’t be bothered actually getting TextMate to work. See, its blogging extension’s bundle’s idea of configuration is to have you put your blog’s XMLRPC address in a text file. We gave it a couple tries at what we think that address should be for this blog, but it failed to make them work. And we figured we just wouldn’t bother to keep trying, since obviously there wasn’t going to be any useful conveniences here at all, so at best it would make it into the same class as the other non-WYSIWIG tools. So we’ll award it 2/10 to put it at the bottom of our ratings due to its completely beyond the pale requirement of “needing a clue about blog internals” and leave it at that.

Recently, after passing over 1500 iPhone apps across over 1000 publishers, we decided to investigate what strategies successful developers were employing in order to get their apps noticed. What we discovered was that, although only a handful of apps were achieving critical success, many of their publishers (Storm8, Trippert Labs, Digital Chocolate, I-play, Webworks, etc.) were the same guys releasing success after success, and these publishers weren’t all large brands with huge marketing budgets.

So we dived into our ad data and determined that it was actually possible to simply “purchase” enough ad units to brute force an app into the top 100. The cost? Unfortunately, around $1875 a day in ad campaigns.

How do you come up with that? From the well worth reading downloadable PDF report,

You need about 2500 daily downloads to crack the top 100 in a popular category (the iPhoneapp POW by Inedible Software hit top 60s in Entertainment with 2800 daily downloads).

With untargeted ad impressions converting at a high estimate of 0.2%, we need 1.25 million ad impressions to get 2500 downloads.

Ad networks typically sell inventory on a CPC basis, at a minimum of 5 cents per click. With top networks performing at around 3% CTR, 1.25 million ad impressions generate 37,500 clicks.

This translates to a one day minimum cost of $1875, which is probably too expensive for many developers.

Indeed. And should you think their vested interests are overstating that, here’s an anecdotal agreement:

Fortunately, I know someone from the original Grocery iQ team. Grocery iQ was able to win the triple crown of apps: a Top 100 ranking, Apple Pick of the Week, and being featured under “What’s Hot.” What was its secret to success? When Apple released its Top Apps of 2008, Grocery iQ was in the top 50. I think that makes the Grocery iQ team qualified to talk about App Store success.

Jason’s first response to the $1,875 per day price tag: “Yup, that’s about right!” The Grocery iQ team dabbled with paid ad networks and calculated that to make the top 100, they’d have to spend close to that amount for at least two weeks. “Small indie developers simply don’t have that kind of money,” Jason said.

So there you go then. Our general impression had been that people who had tried buying ads for their iPhone apps were completely unenthused about the results … and now we have some hard numbers to back that up!

Colophon:

And we’re just about done with The Great WordPress Client Test, ch-ch-ch-checking out

Qumana 3.2.4!

This one really pushes our definitional requirement of native application, since although it is technically an OS X application package, it’s a bundled Java application. Which means that conventional editing shortcuts don’t work, formatted pasting is apparently nonexistent, and in general it’s ugly and clunky. On the other hand, it actually works the closest to the way we’d like our ideal workflow to go of any of the clients we’ve tried! Not insignificant, that. And you definitely can’t beat the price, given that it’s free; apparently they’re providing this client gratis on the theory that you’ll click the ‘Insert Ad’ toolbar button frequently after joining up with their Adgenta ad service. Which doesn’t interest us particularly. And although we’d really like to give it the much higher rating it’s workflow design deserves, there’s just too much crappiness about a Java app and its not playing nice with content sources for it to rate better than a 5/10. Although, if they ever did come up with a native version that played nicely with others, that would oh roughly double, I’d say…

I thought that people might be interested in the source code for the latest build of our in-house CAD application SonoDraw. A full source bundle, including all supporting frameworks, can be downloaded from here:

http://www.sonoplot.com/SonoDraw/SonoDrawBundle-2.2.zip

This version finally integrates work that Allan Daly and Michael Caron have done on the DXFReader framework and its connection to DrawKit.

Peruse the announcement thread on the DrawKit mailing list, and enjoy!

Colophon:

Yes, we’re over halfway now in The Great WordPress Client Test, and today’s victim is:

myWeblog 2.1!

Unfortunately, this one pretty much falls into the same category as MarsEdit; HTML editing only, no convenient rich text editing. And it’s not quite as polished as MarsEdit either. On the upside, it is much more focused directly on WordPress than anything else so far — particularly, this is the only tool (we think) that has support for WordPress pages as well as blog entries. Of course, we’re not actually using WordPress as a CMS so that’s not a compelling feature at the moment, but if we ever do get around to it we will *definitely* give myWeblog another goaround, since HTML-only editing would be ok for pages that we actually do want to craft in some detail, as opposed to our usual strategy of just throwing up something that we might want to search for later. In the meantime … we’ll give it a 6/10 tie with MarsEdit for the ‘semi-casual blogging’ problem space.

Accelerometer Simulator is an iPhone/iPod Touch application that transfers accelerometer data from the device to your computer using UDP protocol.

The main use case for the application is to allow iPhone application developers to create applications that require accelerometer, without having to do all the debugging on the actual device. By inserting two files into their project, they can use the Accelerometer Simulator to provide accelerometer data to their application when debugging on the iPhone simulator…

Nothing special about the simulator, mind you, this code could also be applied to sending realtime data from an iPhone app to any other desktop app. Which has some intriguing possibilities. In the meantime, grab the project from Google Code, and using it really couldn’t be any simpler:

To embed Accelerometer Simulator capabilities into your own application, simply add the AccelerometerSimulation.h and AccelerometerSimulation.m files from the Simulator classes directory into your project. Then in the source file where you configure UIAccelerometer, simply add

#import “AccelerometerSimulation.h”

This will override the default behaviour of UIAccelerometer when run on the iPhone simulator. When building for device, nothing is changed in your application.

And note also this extension which lets you use your MacBook’s accelerometer to provide the data. Not that we can really think of an actual compelling use case for that … but hey, it’s a nifty hack, and who doesn’t love nifty hacks?

h/t: If ( … ) then { … }!

Colophon:

And it’s day 4 of The Great WordPress Client Test, and today we’re using:

MarsEdit 2.3.2!

Now this is a right switchup from yesterday, when we ran screaming from MacJournal because it doesn’t have a HTML editing view; today we’re tossing MarsEdit out of serious contention because it doesn’t have a WYSIWIG view. Yes, the live preview is excellent, and yes the immediate image uploading is well done, and there’s lots of other good things about it … but although we want optional control over all our HTML, we’re not interested in mandatory control, that’s just too much effort. So we’ll give MarsEdit a 6/10 for being a very nice tool indeed if you do want complete control, but being unduly complicated for semi-casual blogging like ours. Yes, we’re hard to please, we know. Just call us Goldilocks.

Juggernaut A in this case is AdMob, which it seems is the current biggest ad server in the mobile space, and Juggernaut B is AdWhirl, which makes a pretty compelling case to sign up with it by acting as a mediation layer instead of a direct provider. This did not go over well with Juggernaut A, so they decided to take their toys home with them:

Beginning July 22, AdMob will no longer serve ads requested from iPhone apps that employ ad network mediation layers such as AdWhirl or Tapjoy. This change will enable us to provide our publishers and advertisers, as well as end users, with the best possible experience and results…

Yeah, sure. We were raised on a dairy farm, so we know exactly what we’re smelling here. And so do most others; the discussion on the iphonesb list was … spirited, with threads like Who hates AdMob today? Hard to miss that sentiment, indeed. However, as you can see in the admob blocked adwhirl, now what? thread, Admob does indeed generally make up the bulk of revenues. Which is why, as this particularly perspicuous post portrays,

My theory goes as such: AdMob is frightened. They have a dominant position, but suddenly an influx of competitors has put the heat on 
them. I mean, frickin’ 800-pounds-ads-gorilla Google is getting into the game. And AdWhirl allows them to switch at a moment’s notice.
So, they make the decision to “balkanize” the target: “with us or against us”. They say: if we stop serving ads to AdWhirl now, when competitors can’t match our inventory and payouts, the large number of people having us as a primary revenue stream will have to switch to the AdMob SDK or lose us as a revenue stream. Makes sense in context.
Of course, this situation is not going to last. Competitors will eventually start to catch up to AdMob (I mean, frickin’ Google). And AdWhirl is a mid-to-long-term competitive advantage too large to drop…

Yep, we’d agree with that. There’s lots of other good insight in that thread worth checking out, too, but you get the gist of it.

Also note the thread My E-mail to AdMob about the adwhirl isssue, which sideslips into a discussion of new ad player MdotM, in which the founder shows up to fill in some background on it; and some more hard numbers on advertising return for your consideration in that thread as well.

And finally, if you haven’t come to a firm conclusion about which direction to take your ad-supported iPhone programming yet, then read this last thread, Thanks for all the support – AdWhirl, from one of the AdWhirl cofounders:

In terms of updates, we’ve been in communications with AdMob and the big requirement for them was not that developers couldn’t use both AdWhirl and AdMob, but rather, since they couldn’t tell when a developer was using AdWhirl to cycle through AdMob ads (since we requested directly from the library), they had to ban anyone using AdWhirl. That was why, after talking to them, we immediately pumped out a new version of the library that pulled AdMob’s SDK out, and differentiated our ads from AdMob’s ads. Developers can now safely implement both AdMob and AdWhirl with their own logic, but of course AdWhirl has no visibility into what is happening with AdMob and can’t help facilitate any optimization, customization, or ad tracking. (our blog post about this is here: http://www.adwhirl.com/blog)
Keep in mind, though, AdWhirl isn’t just about maximizing revenue and optimizing fill-rates (although we do that, too!) – we allow developers to create their own custom ads dynamically (both icon+text as well as full-width banner images) and link to wherever they’d like to. We realize other ad networks / companies will soon be following suit with their own house-ads products, but keep in mind that, as an OPEN PLATFORM, AdWhirl is planning to open up our community of over 1000 publishers across over 1500 apps, such that you guys can soon start helping one another directly with cross-promotion and getting apps past the top 100 without paying several thousand dollars to an ad network. There’s value in this community as you guys have clearly known for awhile!
Plus, we’re going to be offering new ways to monetize soon that break the whole advertising paradigm.
The important thing is we’ve worked really hard to make sure you guys aren’t forced to make a choice, which is what our open platform is all about.

Well, we know who we’re going to bet on as the long term iPhone advertising success story here!

Colophon:

For day 3 of The Great WordPress Client Test, our post is courtesy of

MacJournal 5.1.3!

This one, well … it’s not called “MacBlog”, you may notice — and that is for good reason. Although I suppose this “journal” concept must appeal to some not insignificant body of people or else it wouldn’t be into version 5, it’s just not designed as a blog management tool. So there’s really no point listing specific issues with WordPress, we’ll just jump straight to the conclusion of “pick something else” and give it a 3/10 for getting a post up with a picture, although we had to sort out a really annoying amount of formatting and metadata afterwards, and HTML editing is just not available!, which puts MacJournal right off the WordPress coder geek reservation far as we’re concerned.

I’d like to allow my user to double-tap the map view to place an annotation marker, rather than the default zoom behaviour. What’s the preferred method of having my program intercept touch events, then either passing them along (single-touch) or not (double-tap)?

Well, here’s a question on Stack Overflow that answers that for MKMapView and probably UIWebView as well: create a wrapper view that intercepts the various touch events, then place the functional view inside it, like this:

#import <MapKit/MapKit.h>
- (void)applicationDidFinishLaunching:(UIApplication *)application {

//We create a view wich will catch Events as they occured and Log them in the Console
viewTouch = [[UIViewTouch alloc] initWithFrame:CGRectMake(0, 0, 320, 480)];

//Next we create the MKMapView object, which will be added as a subview of viewTouch
mapView = [[MKMapView alloc] initWithFrame:CGRectMake(0, 0, 320, 480)];
[viewTouch addSubview:mapView];

//And we display everything!
[window addSubview:viewTouch];
[window makeKeyAndVisible];
}


Colophon:

Second day of The Great WordPress Client Test, and today we’re checking out

ecto 3.0!

Now this acts much more like a Mac program should. Interface is intuitive, category/tag/image composition beats Blogo all hollow, we like that ‘Amazon Helper’ plugin idea, … but there’s some quibbles here too:

• The Preview window is resolutely blank. Blogo, now, it did a nice job of downloading all the appropriate templates from the blog. On the other hand, ecto actually uploaded it as expected and didn’t muck up the categories or lose text and so on … so we don’t count that as a major flaw.
• Doesn’t seem to be a way to blockquote selected text, you have to click into blockquote mode then paste apparently. Not a dealbreaker I suppose, but I do rather like the online editor’s behavior that blockquotes the paragraph containing the insertion point.
• It doesn’t maintain the Undo stack between HTML/text view changes either, even if you don’t actually do anything but switch between the two views.
• Whilst in general the HTML creation and paste handling is excellent, and it’s a brilliant feature to actually force the HTML to be correct before leaving the HTML editor and offer to fix it for you like ecto does … in the particular circumstance where we’d like to paste source code in and slap <pre> tags around it, this feature actually gets in your way as it insists on making every line a new paragraph, which is not what we want as it loses the indentation. Perchance there’s a way around this, but it’s not immediately obvious.
• The initial publish disallowed trackbacks/pingbacks. Presumably that’s a trivial setting fix somewhere, but allowing them really should be the default we think…

So yeah, we like this ecto thing overall, we’ll give it a solid eight from first impressions. Definitely worth an indepth evaluation probably … but we’ll see if we’re completely starstruck by any of the remaining five!

#import <mach/mach.h>
#import <mach/mach_host.h>

static void print_free_memory () {
    mach_port_t host_port;
    mach_msg_type_number_t host_size;
    vm_size_t pagesize;

host_port = mach_host_self();
    host_size = sizeof(vm_statistics_data_t) / sizeof(integer_t);
    host_page_size(host_port, &pagesize);        

    vm_statistics_data_t vm_stat;

    if (host_statistics(host_port, HOST_VM_INFO, (host_info_t)&vm_stat, &host_size) != KERN_SUCCESS)
        NSLog(@"Failed to fetch vm statistics");

    /* Stats in bytes */
    natural_t mem_used = (vm_stat.active_count +
                          vm_stat.inactive_count +
                          vm_stat.wire_count) * pagesize;
    natural_t mem_free = vm_stat.free_count * pagesize;
    natural_t mem_total = mem_used + mem_free;
    NSLog(@"used: %u free: %u total: %u", mem_used, mem_free, mem_total);
}

If your application has non-trivial memory needs, you might be well served to bring that up at launch and tell the user to reboot if memory is low, for instance!

Colophon:
For Day 1 of The Great WordPress Client Test, this post is brought to you by:

Blogo 1.2.8!

Assuming, you know, you’re actually reading this, it does indeed set up and work transparently with WordPress 2.8, but there’s a few things that less than thrilled us:

• We’re not overly impressed with the HTML it produces compared to the online editor. We found extraneous paragraphs and the like once uploaded and we noticed that it broke the #include statements.
• Switch from rich text to HTML mode and back, or to edit mode and back, and you can’t undo. The online editor gets that right.
• Pasting and formatting that code snippet had a variety of associated annoyances; pasting in the wrong place, thinking the #includes were followed by tags or something. Eventually we deformatted the copied text in TextEdit and pasted it into the HTML view to get it to not do things wrong. That’s worse than the online editor too.
• We’re just not really fans of the interface. Maybe it grows on you.
• It completely failed to post the above picture — we added that online after posting!
• It ate the filenames in the #include statements during upload, apparently thinking they were HTML tags; we fixed that manually with the online editor. It should be smarter about sorting that kind of thing out.
• It mucked up the assigned categories when posting, and we fixed that manually too.

So there’s a number of reasons to look skeptically at it, and that picture problem is pretty much a dealbreaker, since we do like to put the odd picture in our posts. On the plus side, it does have a lot of nifty conveniences, the previous post editing looks nicely worked out and the setup guidance was a veritable exemplar of how to get people started properly … but we’re just not terribly thrilled with it overall. Out of ten, we’ll give it a four, and if someone happens to know The Magic Trick We’re Missing for getting the embedded picture to upload, then we’d give it a seven. But we’re certainly hoping that the remaining six work out better, even if the image upload fail is something easily correctable … because if not, sticking with the online editor is looking like a better idea.

• Blogo, “The blog editor for your Mac”
• ecto, “Publish to almost any blog from your Mac”
• MacJournal, “Journaling… 2009-style”
• MarsEdit 2, “Powerful Blog Publishing For Your Mac”
• myWeblog, “The weblog editor for people with style!”
• Qumana, “Tools for bloggers”
• TextMate, “The Missing Editor for Mac OS X”

Any competitive tools that I may have missed, Dear Readers? And any strong opinions for or against anything on this list for doing, well, exactly the kind of thing that you’re accustomed to seeing here?

UPDATES: Here’s how our tests of the various clients are going went:

Blogo: Not overly impressed at all. Rating: 4/10. Dealbreaker: Image upload FAIL.

ecto: Nicely done indeed. Rating: 8/10. Annoyance: HTML autocorrect kills pasted code formatting.

MacJournal: Wrong tool for the job. Rating: 3/10. Kinda like taking a plush minivan offroading; perhaps you can manage, but why?

MarsEdit 2: Insufficiently convenient. Rating: 6/10. Yes, we want the option to get all geeky with HTML … but we don’t want to have to.

myWeblog: Also insufficiently convenient. Rating: 6/10. With the note that were we ever to get into actually using the CMS features of WordPress, this appears to be the only tool set up to handle pages as well as posts, so it would definitely rate a reexamination at that point.

Qumana: Java apps suck. Rating: 5/10. Although if it wasn’t Java, it would probably win hands down.

TextMate: Requires a clue. Rating: 2/10(DNF). If MacJournal is a plush minivan, then this is a workshop sandrail.

Soooooo, out of our seven challengers, the only one that’s left standing as a possible replacement for “save web client drafts more often” is ecto. Yikes! That’s really not how we expected this to turn out, with the wide popularity of WordPress we’d sort of assumed that aiming at semi-casual users of it like ourselves would be a not insignificant market slice. Of course, since we’ve been at this blogging thing well over a year now and it didn’t occur to us to even look around for one until whatever it is that’s causing the recent editing instabilities annoyed us once too often last week, well there you go then, apparently there actually isn’t a marketable blog client segment lower than “hardcore HTML geek”. But for the one client that made a good showing, we now bestow our Grand WordPress Blogging Client Trophy For Mid-July 2009 upon ecto 3.0. Congratulations to all the contenders!

In this article, we will present you with all the unbiased and useful links, information and updates about the ins and outs of Web monetization; how intrusive Web 2.0 system monetization methods are, the most common utilized monetization methods and how successful are they. All you need to know about Website, Web application and Blog monetization is summarized with loads of links.

The six main monetization methods are listed in our humongous table below. In this table, we will be discussing, in details and with examples, how intrusive, successful and viable each of the monetization methods is in order to help companies, and start-ups in specific, develop an overall concept of what works most and why…

Indeed. And here is that “humongous” table:

Nothing there so compelling we plan to inflict it upon you immediately, Dear Readers … but if you do have any thoughts on what you find the least offensive and/or most effective in a web traffic monetization kind of way, feel free to leave your thoughts!

13 Apps to Turn Your iPhone into a Blogging Machine