iPhone

iPhone 3.0 and KillExchangeLocks

Posted by Dallas on June 21, 2009
App Store, Apple, HashBang Ind, iPhone, Jailbrake, Programs / 3 Comments

I will be honest and upfront and say I don’t know if KillExchangeLocks will be revamped for 3.0.

I have pretty much totally moved away from the entire Jailbrake scene.
In fact out of all 6 devices I own only 1 is Jailbroken and I only keep that one on hand because I have 2 paid apps that I released back during firmware 1.x and before the AppStore.

I am very sorry if this news comes as a disappointment.

Since 2.0 and the AppStore came out Jailbraking has lost its appeal to me as I use AT&T so that’s not a concern for me and since the only reason I ever got into the Jailbrake scene in the first place was to be able to write my own apps and run other peoples apps on a great device that had so much more potential.

Now with the AppStore it seems like Jailbraking is done for one or more of the following: Carrier Unlock, Apps that Apple won’t approve, and Warez.
I don’t care about carrier unlocks, and I don’t approve of Warez (even if you say you use them as demo’s and buy the ones you like, because 99.9% are not doing that), and that just leaves apps that Apple won’t approve. This would be the only thing to keep me around but Apple lets most things in (it might take a couple rejections first though) that I am interested in.

Also, Apple has been getting really good at closing all the holes that made this app possible (as technically they are security holes).
So much so that the last version “oddly” wouldn’t work for everyone, including me.
I spent a ton of time searching for new ways back then and never found anything that I was happy with, and then I finally gave up and just stopped syncing my work email.

(It was a plus for my day job to have me accessible by email all the time and I decided it wasn’t worth the time and work I was putting into not having my personal device locked down)

Of course I understand that this isn’t the same for everyone.
All I can really say is I feel your pain (as if that helps anything), and that in a comment on the post way back about version 3.0 of KillExchangeLocks, Eirik mentioned that a new app has just shown up in Cydia called: “Exchange Unlock”.

With that in mind, let me get the “legalize” (if you will) out of the way.
“Exchange Unlock” is not my work, nor do I have anything to do with it in any way.
I have NO idea if it works, and I can not be held responsible if it blows up your device, literally or figuratively.

I do wish you the best of luck, and encourage you to check out my other work at: HashBang Industries (http://www.HashBangInd.com)

Tags: , , , , , ,

Coming Soon to a Bookstore Near You

Posted by Dallas on May 05, 2009
Apple, Cocoa Touch, iPhone, Objective-C, Personal, Programming, SDK / No Comments

I have been offered a gig of being the Technical Editor for an upcoming iPhone programming book.

The book is called “Cocoa Touch for iPhone 3.0″ and is being written by my friend Jiva DeVoe and published by Wiley and Sons Publishing.

You can visit the current pre-emptive webpage for the book at: http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470481072.html

I was previously a Technical Reviewer for the programming book: iPhone SDK Application Development, 1st Edition

It will be interesting the see the differences between being a technical reviewer and a technical editor.

Tags: ,

Submitted to App Store

Posted by Dallas on March 06, 2009
App Store, iPhone, Programming / 1 Comment

A while back I wrote another iPhone application that was mainly for myself, but the business side of me said, “If I wanted this app enough to write it, chance are there are people willing to pay a couple bucks for it.”

The down side of this was that I had to develop the application a lot more.
Instead of just having to be “enough” for me, it had to be complete enough to sell and for people to be able to easily use.

So I finished up making it great.
It was done and it was SEXY!

The problem…
The sexy part was the part that connects to your computer, and that part was Mac only.

I did not like the fact that it was Mac only because I knew it would really hurt sells.
So I bit my lip and went about redoing that entire section.
I wanted something that would feel familiar with but that was at least just homely looking instead of looking like a nasty skank.
The problem was that the way to do this was a pretty big undertaking as there was nothing standard for the iPhone and the doing a one-off is a huge task (hence why there is nothing out there).

Finally I found another developer who was in the final status of doing a one-off himself, and he agreed to let me have access to the code.

SWEET! Here was my answer, right? right?

So I went and integrated the code.
Problem was that the code was not complete, but that was alright because I still had a bunch of little things to finish up and I was under the impression that the other code would be finished shortly.

So I finished everything up, but still no updates on the other code…
CRAP!

So I started looking into the code to see if I could find where the problems were, but like I said before, this is a BIG undertaking of code and I had no insight of the under workings of that section.

However now all my code was done, so I needed this last part done.

Off and on I would spend a day or two digging into the code, and hitting up the developer for any word on updates.

Now 2 months after I finished my end, I was still in basically the same spot and still no word on anything anytime soon.

Finally last night I said, “screw this”, and I decided to go with the Skanky version for now, knowing that I could always go back if/when the other code gets finished, but just sitting here was doing no one any good.

Earlier today I finished the coding aspect of the new setup.
Then I just had to do a screencast help video and do all the paper work type stuff on the App Store.

Then it was off to the races!
Application SUBMITTED!

Now it’s just time to hope that it gets through the Apple review process, and quickly.

Oh and to be honest, this new way probably isn’t really Skanky, but it just kind of feels that way to me after my original design.

KidFlix in Review

Log all accessed methods in Objective-C with DTrace

Posted by Dallas on February 07, 2009
Cocoa, Cocoa Touch, DTrace, iPhone, Mac, Objective-C, Programming / No Comments

I have recently been debugging some Objective-C and Cocoa/Cocoa Touch code.

Not being familiar with all the code and with a TON of methods being accessed in milliseconds, my attempts at stepping through the code just wasn’t working, as clicking ‘Step Into’ as fast as I could keep up and over an hour of stepping through I was still not even close to figuring out what I needed to know.

This lead me to the thought of logging every method that was accessed and then I could step look through it and skip around as needed.
However with 60 some odd files and say maybe 20 methods in each file, that would take a lot of NSLog’s.
I started looking around and was pointed to bbums blog about doing something similar.
However it still would take adding some code, plus I couldn’t get it working right with the iPhone.

This lead me to wonder about DTrace.
After a recent podcast from Scotty at the Mac Developer Network, featuring Colin Wheeler talking about DTrace, I have been very interested in learning more about DTrace.

The difficult thing I have been finding is that since DTrace was originally written for Sun, it is hard to find info related to MacOS and more so Cocoa.

I then found a video from Colin about using DTrace with Cocoa and XCode.
http://www.viddler.com/explore/Machx/videos/8

I wasn’t able to get what I wanted working, so I hit Colin up on Twitter and then talked to him a bit in email and he pointed me to the Golden Solution!

The solution is:
objc$target:::entry{}

So I took that and created a DTrace script.
You can grab it here:
http://kdbdallas.com/wp-content/uploads/2009/02/logallmethodsd.zip

To run it open Terminal and run:
sudo ./logAllMethods.d -p PID

Of course replacing ‘PID’ with the PID of your running program and remembering that for DTrace ‘sudo’ is required.

Also note that this works for iPhone programs running in the iPhone Simulator.
Just look for the PID of your iPhone app within Activity Monitor once it’s running in the simulator.

Be careful as depending on the program it can spit out a TON of data VERY quickly.

Running this against Adium for only a fraction of a second gave me a couple hundred lines of output.

The output looks like this:

tesseract:Desktop dallas$ sudo ./logAllMethods.d -p 4371
dtrace: script ‘./logAllMethods.d’ matched 71222 probes
CPU ID FUNCTION:NAME
0 59398 -retain:entry
0 34684 +retain:entry
0 32061 +idleAllMovies::entry
0 32062 -idle:entry
0 34707 -retain:entry
0 32914 -_usingVisualContext:entry
0 32878 -_resyncNaturalSize:entry
0 31935 -loadState:entry
0 31972 -naturalSize:entry

Hopefully this helps someone out there.
Just remember always use the info I post for good.
(or if its for evil make sure it profitable and then send me a cut)

Once again, special thanks to Colin Wheeler.

Tags: , , , , ,

Mac/iPhone: Show Available Usable Disk Space

Posted by Dallas on December 27, 2008
iPhone, Mac, Objective-C, Programming / 6 Comments

If you have an application that allows users to upload content to the app, you might want to show the user how much space is available for them to use.

This is especially true on the iPhone where it is not as easy for the user to quickly check if they have enough room to upload a given file.

You may also want to check if there is enough space before you start the upload, so you can inform them that the file wont fit.

That brings you to the task of figuring out how much free space there is, and more importantly how much free space is left that you as an unprivileged program can access.

The following code is based towards the iPhone, however all that would be needed to change it to be used on the Mac is the location you are checking for free space, and the setting of the label.

NOTE: The below “shown” code is old. The updated code is in the zip file at the bottom

#include <sys/param.h>
#include <sys/mount.h>
NSString *sizeType;
 
float availableDisk;
 
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
 
struct statfs tStats;
 
statfs([[paths lastObject] cString], &tStats);
 
availableDisk = (float)(tStats.f_bavail * tStats.f_bsize);
 
if (availableDisk > 1024)
{
	//Kilobytes
	availableDisk = availableDisk / 1024;
 
	sizeType = @" KB";
}
 
if (availableDisk > 1024)
{
	//Megabytes
	availableDisk = availableDisk / 1024;
 
	sizeType = @" MB";
}
 
if (availableDisk > 1024)
{
	//Gigabytes
	availableDisk = availableDisk / 1024;
 
	sizeType = @" GB";
}
 
diskSpaceLbl.text = [[@"Available Disk Space: " stringByAppendingFormat:@"%.2f", availableDisk] stringByAppendingString:sizeType];

This will give you something like the following:

availablediskspace

UPDATE:
I have gone a step further and made this into an easy to use class, that works out of the box with the iPhone and the Mac.

FSStats.zip

Tags: , , , ,

The App Store Effect

Posted by Dallas on December 27, 2008
App Store, Apple, iPhone, Programs / No Comments

Great article over at Inside iPhone. Very worth the read.

http://blogs.oreilly.com/iphone/2008/12/the-app-store-effect.html

Snapper-brand lawn mowers are expensive. Many Snapper products cost thousands of dollars, and even their simplest push mower is hundreds of dollars more than some competing products. Snapper lawn mowers are not cheap. What they are, however, is reliable. They’re manufactured well and designed to last for years. Snapper believes that a premium-quality product can command a premium price. They’ve built their business around that idea, and that business has been around for nearly 120 years.

In 2002, as CEO of Snapper, Jim Weir went to meet with Walmart executives. Walmart has thousands of stores in the US, and millions of customers walk through their doors each day to purchase nearly a billion dollars in goods. Yet Weir went to Walmart’s Arkansas headquarters to tell them he was pulling his products from their stores.

The problem for Weir, and Snapper, was the very essence of Walmart itself. Walmart sells customers disposable goods at the cheapest possible price. At the time, Walmart had six different push mowers for less than $200, while the cheapest Snapper listed for $350. These low prices change expectations across the board, and leave customers wondering what they could possibly be getting with a Snapper to justify the much higher price. With no expert salespeople to educate them on the tradeoffs between price and quality, most consumers opt for the lower-priced product. Over time, higher-quality goods are forced to lower both their prices and their standards in order to compete. The quality level of an entire market is eroded, ratcheted downward more and more.

Weir chose to break this cycle by pulling his products from Walmart entirely. Snapper instead focused on the knowledgeable independent dealers who could educate consumers on Snapper’s legendary quality and explain just why the higher price was worth it. Even without Walmart, Snapper has grown since 2002, and they’ve managed to maintain their identity as a premium-quality manufacturer.

Weir’s story brings to mind a comparison between Walmart and the App Store. The reasons behind it aren’t identical, but just like Walmart, the App Store is driving down prices of applications across the board. The price floor isn’t $5 as I predicted back in June, but $0.99, the very lowest price it’s possible to charge for an application in the App Store. If developers could charge a price lower than 99 cents, there’s no doubt that some would, and the price curve would shift even lower.

On the face of it, these low prices may seem like a good thing. The more affordable iPhone apps are, the more customers will purchase, leading them to try out many different products. When price is no longer tied to a developer’s costs, however, the market is unstable. The first application to cut its price and successfully rocket to the top of the App Store sales charts will see an enormous jump in sales. As we’ve seen, this cycle repeats over and over, and those developers who reach the sales charts do very well. As the average price is driven down, however, a negative-feedback loop is created. A low price is required to get a top sales spot, and only the sales volume that such a slot brings makes development sustainable. Fewer and fewer customers will pay a premium price, so all developers are forced to slash prices to chase a top sales spot.

While there are dozens of new applications each day, the number of slots in the Top 100 is, obviously, unchanging. As consumers come to expect ultra-low prices, more and more developers will wind up earning less for their software than it costs to develop. That will lead to developers ending development of existing products or simply opting out of the platform entirely. The low prices the App Store has led to will directly affect the quality of what’s available in the App Store.

Certainly, some developers are attempting to counteract this App Store effect, by providing higher quality products at a higher price. SimCity, currently the #2 selling app, has a $9.99 price tag. However, that’s a game with an established brand; top sellers have by and large been $0.99 applications. It’s difficult to look at iFart Mobile, which has sitting at #1 in the App Store for nearly a week, and view this as a quality, stable marketplace for developers or consumers. The App Store, like Walmart, has been reduced to selling disposable goods at the lowest possible prices.

Unfortunately, unlike Weir and other vendors of premium products, iPhone developers have no other way to get our products to customers. We can’t sell direct to customers, or via any other stores. At this time, our options are to be in the App Store, or to not sell our software on the iPhone. This makes it very difficult to command any sort of price over $0.99.

The math is simple. It costs more to make an application with depth and quality. In short order, the App Store effect will prevent the development of these deeper, higher-quality applications for the iPhone. When developers can’t charge a higher price to cover a higher investment, these applications simply won’t be made at all.

Using Your iPhone Sim On The Android Dev Phone

Posted by Dallas on December 14, 2008
Android, iPhone / 4 Comments

If you have AT&T (with say an iPhone) and get the Android Dev Phone, you can use your iPhone’s Sim with the G1 as it is both hardware and software unlocked.

When you insert your Sim and then start up the Dev Phone for the first time you will come to the first page of the setup.

Click on the Menu button and click Add APN.

Now enter in the following information:

Name: att
APN: wap.cingular
Password: CINGULAR1

Leave all the other fields blank.

Now click on Menu again and choose Save.

That should be it! You can now use your Android with your AT&T account.

Tags: , ,

Android Dev Phone

Posted by Dallas on December 14, 2008
Android, iPhone / No Comments

I received my Google Android Dev Phone this weekend.

If you don’t know the Dev phone is a G1 that is fully unlocked (hardware, and software) and allows itself to be loaded with unsigned firmwares.

Here are some pictures as well as a few comparing it to the all mighty iPhone.

img_4918img_4920img_4922

img_4923img_4928img_4930

img_4931img_4933img_4938

img_4941img_4942img_4943

img_4946img_4947img_4948

img_4950img_4951img_4953

img_4954img_4955img_4957

img_4960

Tags: ,

Pi Presentation: SQLite

Posted by Dallas on December 04, 2008
Cocoa Touch, iPhone, Objective-C, Programming, SDK / No Comments

Last night I gave a presentation at the Phoenix iPhone Developers Group (Pi) on SQLite.

I am posting the presentation and sample code here for anyone who is interested.

Please note that this is by no means the “proper” or only way of doing things. This is simply one way of doing it, and is for reference purposes only. The code uses the FMDB SQLite Wrapper.

Example Code: (example.zip)

Keynote Presentation (sqlite-presentation.zip)

Tags: , , ,

Developers and the App Store

Posted by Dallas on December 02, 2008
Apple, iPhone, Jailbrake, Programs / No Comments

Most of the following was in response to the blog article by Layton Duncan of Polar Bear Farm.

iPhone developers were happy to see the AppStore come to life as it gave us a official way to release our app to the world. Little did we know that people would freak out about having to pay even $1 for apps, when before the App Store we were selling to the Jailbrake community for $10 or so, without complaint.

The $1 app issue is unfortunately not one that I think Apple can fix, as it’s not them causing it. It’s the consumers. Consumers seem to have it in their head that it is ok to pay $5, $10, $20 and up, for desktop applications, but that an iPhone app for some reason shouldn’t cost more then $1. Maybe they are stuck in the mind frame of old school cellphone apps/games that were absolute crap and not worth more then $1 (if even that), or if they just don’t understand what it really takes to make a beautiful, stable iPhone application.

Personally I think it is a combination of those 2 and that when the app store opened people were not sure what to charge, and some of the bigger name companies came to the AppStore with free and low price apps, and this set the consumers in a mind frame that free or almost free is what is expected. Who knows, maybe they are just cheap. The only way around this that I can see is for all or at least a large amount of developers to “ban together” and start charging a fair (to both sides) price.

No doubt it will hurt sells at first but perhaps we can get passed the misguided mentality.

Tags: ,