Generating Random Numbers, Strings and Data in Objective C

Posted on by

Today I’m open sourcing JFRandom, a powerful utility class for creating random numbers, arrays of these as well as random strings and data.  It’s available for free download over at github.

I’ve been using this class in my KEYBOX product for nearly a year now and I can attest to its robustness.  JFRandom works in both ARC and non-ARC projects for both iOS and OS X.

Whether you need random data for encryption purposes, video game AI, shuffled music playback or just lucky lotto ticket numbers, JFRandom has you covered.

 

How to Use JFRandom

JFRandom is very simple so I’ll just illustrate one-liner examples of the main functionality below.

 

For single random numbers…

NSInteger number = 0;BOOL worked = [JFRandom generateNumberBetweenLow: 0 andHigh: 100 intoReceiver: &number];

 

For arrays of random numbers…

NSInteger sequence[100];BOOL worked = [JFRandom generateNumberSequenceOfLength: 100 into: sequence betweenLow: -1000 andHigh: 1000 withOnlyUniqueValues: NO];

 

If you need each number in the array to also be unique do this…

NSInteger sequence[100];BOOL worked = [JFRandom generateNumberSequenceOfLength: 100 into: sequence betweenLow: -1000 andHigh: 1000 withOnlyUniqueValues: YES];

Note that creating unique number arrays can cause performance issues as the existing selection must be first examined for instances of the next random number to place within.

 

JFRandom also generates random NSData instances…

NSData *data = [JFRandom generateRandomDataOfLength: 16];

 

If you need the bytes to be signed rather than unsigned…

NSData *data = [JFRandom generateRandomSignedDataOfLength: 16];

 

And of course if you need a string full of random characters it’s this easy…

NSString *text = [JFRandom generateRandomStringOfLength: 64];

 

These are the basic capabilities of JFRandom.  There are a few more methods that allow for randomly picking of numbers within a pre-determined array etc…  Check out JFRandom now and save yourself the trouble of coding and testing this yourself!

iOS and Android Fragmentation – A Developer’s Perspective

Posted on by

Disclaimer: The impetus for writing this article is in response to the naysayers in the Android camp who would have consumers and developers alike believe that Android fragmentation is a myth. I’m here to prove that it is not only very real but very costly to dismiss as a myth. In short, I want to arm people with the correct information. I’m an iOS developer and an Apple fan. I have never owned an Android device although I’ve participated in a development project where Android fragmentation reared its ugly head and I’ve also developed extensively for feature phones which exhibited the same characteristics as Android with regard to fragmentation.

What Is Device Fragmentation?

It helps to define fragmentation before going any further.

In a broader context, fragmentation is simply taking one thing and splitting it into fragments. In the context of technology, fragmentation is the act of offering instances of one thing that, while labeled as a single brand, are distinct enough from one another to be considered separate.

By this definition Android is fragmented, as is iOS (albeit to a much lesser degree which will explored later on), and even computers.

Android Fragmentation

So what makes Android so fragmented?  The short answer: Android device makers.

They have to fragment Android in order to compete. Consider the alternative. If Sony offered essentially the same device as Samsung with the same technical specs what advantage would there be in purchasing one over the other? The only alternative would be to compete only on price but that could start a price war resulting in diminished profit margins for both companies. It is therefore in the interest of every serious Android device maker to innovate and outgun its competitors in the Android space (as well as against the offerings of Apple and Microsoft).

Now that I’ve established that the only thing Android device makers share in common is the word “Android” and that they have little choice but to fragment, it’s time to ask the next pertinent question: How does this fragmentation actually take place?

Since Google doesn’t itself manufacture Android devices (Google does work closely with some manufacturers however) there is a lot of wiggle room for device makers. To understand this better let’s look at the breakdown of an Android device…

  • The maker specific hardware
  • The base Android OS
  • The maker specific platform added to the base Android OS

The hardware plays the biggest role in fragmentation. Device makers cater to their respective markets. Some devices lack bells and whistles in a bid to remain affordable for consumers not willing to pony up for a premium phone for instance. At the other end of the spectrum are the Samsungs and Sharps of the world. Below is a list of some areas where makers customize their devices.

  • CPU speeds
  • RAM memory capacity
  • Antenna strengths
  • Storage space
  • Storage I/O speeds
  • Display resolution
  • Display color output
  • Display input accuracy/sensitivity
  • Presence/absence of hardware accelerated graphics
  • Presence/absence of various ports for external media and devices
  • Camera resolutions
  • Battery life
  • The list goes on…

The base Android OS is arguably the area with the least fragmentation. This is the part for which Google is responsible. Some like to view the low penetration of the latest Android OS on newer devices as a kind of OS fragmentation. It’s not quite the type of fragmentation I want to discuss here but it is true that since device makers stand between Google and the consumer, OS updates don’t occur as optimally as with iOS.

The maker specific platform that is slapped on top of the base Android OS is an interesting topic. It renders Android more a meta-platform than a real platform. The Kindle Fire is an example of an Android device that takes great liberties with regards to the UI. In fact, it almost doesn’t expose its Android heritage at all. The look and feel of this layer is one apps that hold themselves to high standards should strive to match when possible and this forces the apps to choose certain devices to support. As an aside, Ars Technica recently reported how Amazon’s market leadership is rendering Google’s control of Android weakened.

 

iOS Fragmentation

Okay I’ve discussed Android a bit, it’s time to take a look at iOS. Unlike the multi-party affair that is Android, iOS and the devices on which it runs are made only by Apple. While this leads to a much less fragmented platform, iOS is not perfectly immune to fragmentation.

Each new iOS device boasts a slew of hardware improvements over its predecessor and with them, you guessed it, fragmentation. Even at a single point in time there are 3 flagship iOS devices: iPhone, iPod touch, iPad with different specifications.  Most of the elements I mentioned for Android above are present on iOS as well.

Supporting many generations of iPhones or iPads can be tedious. However one generation per year is more manageable on the pocketbook. The 4th generation iPod touch is relatively cheap at $199 US and aside from its lack of telephony components is essentially an iPhone 4 and can substitute it for most testing.

Wikipedia has a comprehensive list of iOS devicesand their specs but I’ll focus on the types of fragmentation I have personally found on iOS.

  • The color output on my iPod touch is slightly bluer than that of my iPhones and I’ve had to take that into consideration when designing icons and graphical elements.
  • The iPod touch has only 256MB of RAM despite offering Retina Display resolution which means developers of memory hungry apps need to hand test them thoroughly and optimize for these constraints.
  • GPS accuracy diminishes with the iPod touch and Wi-Fi only iPad since they cannot avail themselves of cell tower triangulation.

And that is basically where fragmentation ends.

To the delight of developers, the resolution of the iPhone and iPod touch has remained 320×480. When Retina Display was introduced the only change was the resolution unit from pixel to point (1 point being a 2×2 pixel area). The new iPad has followed the same approach of staying with a resolution of 1024×768. The iPad’s split view design with its left side table view having the same width as the iPhone’s screen makes it easy to port iPhone apps to the iPad while retaining the same look and feel.

Why should all this make developers happy? We have only ever needed to consider one resolution for our apps on each device class. This gives us the time and freedom to strive for a pixel perfect look without having to contend with container based stretching and contracting layouts that adjust to match various resolutions but look less polished.

 

Ramifications of Fragmentation

I make fragmentation sound like a bad thing. I indeed view it that way. As a developer fragmentation introduces more work and incurs more cost to deliver a quality product.

You could argue that fragmentation is innovation by a different name and that it is good for consumers. More choice, more competition and all that. However there are also grave demerits for consumers. The sheer selection of options can be a dizzying experience comparable to buying a DIY computer with all the trimmings. At the time of this writing Google lists 225 Android devices on its web site.

 

My Experience with Fragmentation

I now want to take the word “fragmentation” from being just a distant, technical concept to what it is really is, a mental and financial burden. Let me share a couple real live experiences I have had with fragmentation. Only then can you relate to the pain and truly understand what awaits you.

Before making its way to the iPhone, KEYBOX was a J2ME app for the Vodafone Japan market. J2ME was, in its day, the only real platform for mobile phone development (BREW wasnt a real competitor). But it was fraught with the identical fragmentation issues that Android developers now face. Each device had a different screen resolution, different color output, different CPU etc… But it was worse, some devices didn’t even support transparent/translucent PNG files or floating point math operations. There was no rich UI toolkit to speak of and if you wanted to make information-based apps with text boxes, buttons and the like you had to contend with the limited selection of device-specific controls with different look and feels. Sun has never been a leader in user interfaces the way Apple or Adobe/Macromedia have and didn’t think to standardize the UI the way Macromedia did with Flex.

I hold myself to a higher standard so rather than settle for inconsistent controls I rolled my own tile-based UI kit that detected the optimal dimensions for windows and such for each device. It was a pain to say the least.

J2ME KEYBOX J2ME KEYBOX

 

I later parlayed my own creative development into professional work opportunities in mobile. The most challenging of which was a DoCoMo J2ME app named Harumin. Harumin was an avatar based television guide and remote control app for the then upcoming Foma 900i series.

(Harumin character – Designed by Spring Design)

Of the 5 devices in this lineup the flagship was the Sharp SH900i and the worst was the Fujitsu F900i. Getting the same code to send infrared signals to a TV from all the handsets was impossible. The Sharp unit was too fast and the Fujitsu unit too slow. We ended up writing device detection logic to throttle the speed. Antenna strength was flaky with the Fujitsu unit and caused us to refactor our network communications logic and last but not least button clicks were interpreted as presses on the Fujitsu unit whereas all other devices considered button releases (the correct way) as clicks.

Long story short, had we not had access to all the devices there is no way we could have made the app accessible across the entire series. Fragmentation was a pain for us, not a plus. It cost us double the time to develop and test our app because of it.

Going Forward

Where I fault Android is that it had J2ME’s failure to learn from but chose not to. Google has now dug itself into a hole from which it will prove difficult to escape.

What attracted device makers like Samsung, HTC, and Sharp to Android was its openness/cost and branding. However if Google were to begin dictating conventions and standards to device makers in a bid to steer Android in a single direction the way Apple does, it may find them abandoning Android and perhaps even spawning a competing fork of it. Even without such moves, Amazon has forked it and it has been speculated that the openness Google prizes could very well be Android’s undoing.

 

Cutting Apple Some Slack

Regardless of how you feel about openness you cannot deny that Apple is in an enviable position. It only needs to answer to developers as it steers the iOS platform forward. There are no device makers to appease.

Apple has kept fragmentation under control but has fallen victim to criticism concerning its tight control over its platform.

Prior to the iPhone if you wanted to make slick games that reached the masses you had to buy a development kit from Nintendo at the ever affordable cost of tens of thousands of dollars. And you had to prove you were worthy of one as well. Nintendo’s pre-sale curation process makes Apple’s look like the wild wild west.

Coincidentally, the only reason one would want to make a game for a Nintendo console like the Wii is the almost complete lack of fragmentation. If your game works on the development Wii it will work on every Wii unit in the wild. The savings in development, testing and support time might just justify the price if you have a hit game and have the money upfront. The Android of this scenario is PC gaming with DirectX or OpenGL which is harder (testing graphic cards etc…) but doesn’t require permission from anybody.

All in all, Apple has successfully struck a balance between the democratization of development for the masses and the offering of a simple platform. For less than $100 a year (and the one-time cost of a Mac and an iPhone) developers can make games and apps. $100 is quickly recuperated even with zero advertising/marketing.

The App Store is such a success that even Nintendo is feeling the heat of Apple’s foray into portable gaming.

Android has tried to emulate the success of the App Store but it has been hit and miss. Independent developers cannot afford the full gamut of even the current generation of Android devices and must pick and choose which devices to target if they are serious about ensuring full support. Such choices are not trivial and involve much research into demographics and device preferences. By the time the project is finished the devices against which it was tested are no longer the latest and greatest as well.

Potential for Further Fragmentation

The rumors of an iPad mini or a slightly larger iPhone never quit. It’s called linkbait and puts food on the table of many a tech writer. Never say never, but so far such reports haven’t panned out. Just recently mock-ups of a purported iphone 5 with a longer screen were leaked. If Apple does go this route it’ll only be if it has found a proper way to allow for existing apps to work well on it and for it to not fall out of people’s pockets. Apple is famous for internally testing products before unleashing them on the public and the form factor we see now exists because it makes sense.

The reason so many deviating form factors exist on Android is not because people are clamoring for them. The marketing departments of device makers are simply looking to “BIGGER is better” as a way to make the public buy their offerings.

It’s still too early to conclude which is better but rather than listen to pundits I’m happy to sit back and watch the market decide.

Conclusion

Android and the innovation it promises are great for the average technology enthusiast but for developers this means dealing with the resulting fragmentation. This can come back to hurt consumers as well. We developers either need to raise prices to justify buying more devices (recipe for failure, especially on Android) or choose certain devices and hope the user base will be big enough.

Apple’s approach is simple and well thought out. It doesn’t need to eliminate the problems that saddle Android because it never created them in the first place. The fragmentation that is present is emergent from obsoleting older models of same device but minimal and even under a severely constrained budget a developer can target a single device and still reach millions of users around the world.

 

The Case Against Universal Apps

Posted on by

Since the advent of the iPad, iOS developers have had the option of distributing universal apps that bundle logic intended for both iPhones and iPads.  But is this a good thing?  In this post I quickly discuss the outcomes of going universal and why they might or might not make sense for your app.

Pricing

You’ve worked hard on your app and you’d like to be fairly compensated for that hard work.

It’s a known fact that iPad users are willing to pay more than their iPhone counterparts for apps specifically designed for the iPad.  If you go universal you’ll have to choose a single, shared price for both devices.  Considering the amount of effort you put in to making the iPad edition of your app that much better for the iPad don’t you think you deserve better?

To add insult to injury, an iPhone user who purchases your universal app will get it for free on the iPad and benefit from the iPad specific parts.  So instead of earning 99 cents for the iPhone edition and $1.99 for the iPad edition you’ll only receive 99 cents, period.

Pricing Experimentation and Sales

You’ll likely be experimenting with your price to find the sweet spot which generates the most revenue.  This number can never be the same on both device classes due to different demographics.

And what if you want to offer a sale for just one device class to bring more awareness to it?  You probably have already guessed that with a universal app you will have to offer your sale price to users of both device classes.

App Size

Why should an iPhone user consume storage space for the iPad specific logic or vice versa?  Storage is at a premium on these devices already.

Code Complexity

Your iPad logic will be living side by side in the same project as that of your iPhone.  You’ll need to detect the device class at runtime and switch between logic.

Staged development

If your time or development budget are strained, you can focus on one device class first by not going universal.  You can determine your app’s popularity after release and decide later on if the other device class warrants a port.

App Store Ranking

Apple views universal apps as being distinct on the iPad and iPhone.  They may share common logic but from the user’s perspective the UIs are very different and any reviews they give reflect the experience of only one of them.  Accordingly Apple separates the ratings and reviews of both device classes in the App Store.  Ratings are believed to major play a factor in App Store ranking so having them separated eliminates any potential for boosting your rank by opting for a Universal app.

When do Universal Apps make sense?

If you have a very simple app that you know will always be free the demerits I mentioned above don’t warrant as much concern.

One merit of going universal is that you can call your app by a single name without appending “for iPad” or “HD” to the title and this can make your app easier to find in the App Store.

Conclusion

In many cases Universal Apps don’t work in favor of developers and in some cases they don’t make much sense for users either.  Careful weighing of concerns should take place first before you commit to either approach.

One thing is certain however, divorcing an already universal app into two entails a lot of effort and can cause confusion for users.  Marrying two editions into a universal app, should circumstances later warrant it, is much simpler.  Just like marriage, you should stay single until you’re absolutely sure you’re ready for it.

Agent App – How To Prevent A Mac App Icon From Appearing On The Dock

Posted on by

If you’re developing a Mac app that runs in the background most of the time (in other words an agent app) you typically don’t want to your app’s icon to consume space on the dock.

Luckily for us, achieving this is quite trivial.  Just follow these steps…

  1. In Xcode (4.3 for the purposes of this post), open the Project Navigator (the folder tab under the Run button).
  2. Select your project (the parent item with the blue print icon).  This opens the project details view.
  3. In the project details view select your app’s main target (under TARGETS) and select the Info tab.
  4. If it is not already present add an ‘Application is agent (UIElement)’ item under Custom Mac OS X Application Target Properties.
  5. Set this item’s value to YES (as shown below).

Application Is Agent

 

And you’re done!

From now on, whenever you execute your app its icon will no longer appear on the Dock or in the Alt + Tab application switcher.

Update to JFUrlUtil

Posted on by

Just a small update regarding the JFUrlUtil URL encoder for Objective C I introduced recently:  I recently encountered URLs in the wild containing the “@” character and accordingly have now added support for encoding it.

The updated JFUrlUtil is available here.

If you find any URLs that don’t encode properly please inform me (jay@jayfuerstenberg.com) and I’ll improve this utility.

Singleton Pattern in Objective C

Posted on by

Objective C unfortunately does not support the singleton pattern with which Java developers are familiar.  The reason stems from the fact that there are no private methods in Objective C to prevent the init constructor method from being invoked.

There is however a simple hack that can provide the benefits of the singleton pattern in Objective C.  Singleton classes tend to be managers of data so let’s go with the class name JFDataManager in this example.

 

Going Global

Since Objective C doesn’t support the singleton pattern we have to resort to using a global variable the way C does.

A global variable can be referenced from anywhere in the application and since we want to discourage the direct manipulation of this global variable we need to hide it.  The best place to hide it is the one place nobody will look, in definition file for that class, JFDataManager.m.

Doing so will render it unlikely of being referenced since we’re never supposed to #import or #include *.m files.  Note that I said unlikely.  Technically any inquisitive developer can find and reference it.

The declaration might look something like this…

JFDataManager *__JFDataManager_sharedInstance__ = nil;

Since the class name was previously declared in JFDataManager.h this instance is completely legal.  Now since we’re dealing with global variables there is the risk of name collision so it’s good practice to go with an instance name that includes the class name as I’ve done above.

 

Exposing It The Recommended Way

The convention for telling developers that they should access the singleton instance and not instantiate their own is to offer a class method beginning with the word “shared”.  You may have noticed a sharedApplication method exposed by the NSApplication and UIApplication classes.  You’ll want to follow this approach.

JFDataManager will expose the below method…

+ (JFDataManager *) sharedManager;

The implementation of this method will return the shared instance and if necessary lazy-initialize it like this…

+ (JFDataManager *) sharedManager {
	if (__JFDataManager_sharedInstance__ == nil) {
		__JFDataManager_sharedInstance__ = [[JFDataManager alloc] init];
	}
	return __JFDataManager_sharedInstance__;
}

 

Getting the shared instance is as simple as invoking the sharedManager method.  That’s really all there is to using the singleton pattern in Objective C.  It involves a bit of trickery but Objective C developers using your class will enjoy the same benefits Java developers already do.

 

URL Encoding In Objective C

Posted on by

A new project I’m working on uses NSURL to a great extent and as useful as that class is, it has one sour point.  It is unforgiving of improperly encoded strings when instantiating an NSURL via the URLWithString convenience constructor.

Naturally I needed an encoder that would escape the unsafe characters.  There is a decent selection online but they each lacked a few properties I need in my project.

  1. The domain + path portion needs to be left alone (no conversion of slashes etc…).
  2. Any previously escaped sequences (like %20) need to be left alone and not have the percent escaped again (like %2520).

I’ve given up looking for an existing solution and rolled my own, which I now share with you!

My implementation is called JFUrlUtil (Download) and is open sourced under the Apache license.

 

How it works

JFUrlUtil features a single public method called encodeUrl.  The approach it takes is basically to iterate over each character in the URL string you provide and escape where appropriate.  It is quite performant as it avoids invoking NSString’s stringByReplacingOccurrencesOfString:withString: method for each unsafe character.

Compatibility

I’ve tested this implementation against tens of thousands of URLs and have yet to find any encoded URL capable of causing NSURL to frown.  If you can find one I didn’t anticipate please let me know (jay@jayfuerstenberg.com) and I’ll gladly update my implementation.

 

When To Localize Your iPhone App

Posted on by

In the past I’ve highlighted some software design mistakes made by others and today I want to point the finger at myself and talk about a mistake I made in localizing my first iPhone app KEYBOX.  It is my hope that this article will help others avoid the same pitfalls I experienced.

I made KEYBOX to scratch a personal itch (digital privacy) and it was first released in 2005 as a J2ME app for Vodafone Japan’s market.As such it was never localized to any language other than Japanese.  That all changed this year when I ported it to iOS.  As the App Store is an international affair I naturally would like KEYBOX to benefit as many people as possible.  The main barrier to this is of course language.

For release 1 I decided to localize KEYBOX into the 4 languages with which I am familiar: English, French, Japanese and Spanish.

I now believe doing so this early was a huge mistake as it introduced two issues for me: serious delays in releasing and numerous layout changes.

In localizing KEYBOX, I underestimated the amount of effort it would take.  There are over 200 text snippets to translate from English.  Using online dictionaries to double check my translations and searching for real-world instances of each text snippet before issuing the final check of approval for each takes upwards of 20 hours for each language.  When you’re only doing this on the side (weekends and some evenings) you can imagine how much it delays the release of your app, which is otherwise feature complete and ready to go.

And then there was the EULA!  KEYBOX is unique in that it requires a rather lengthy EULA to protect myself from users who might be less than responsible with it.  Writing the English version was an experience in its own right.  Writing it in Japanese would’ve been a train wreck without help from my loving wife (also Japanese) and it took over 30 hours spread across 3 weeks.

An interesting surprise was that people in countries whose languages are not yet supported still download KEYBOX, and in droves!  Italy is perhaps one of the biggest markets and KEYBOX isn’t even in Italian yet.  I don’t know if support for Spanish and French is what makes this possible (the Romance language connection?) as KEYBOX is about privacy and I don’t solicit my users for such information.  While I’m sure that supporting multiple languages opens the door to more people enjoying my app, having so many languages supported from version 1 is perhaps less important than I initially thought.

Now to the issue of layout…  In comparison to English, Japanese can be an extremely compact language and most words are only 2 kanji characters in length.  And then there are French and Spanish whose words tend to be much longer than their English counterparts.  This naturally leads to sentences that expand and contract in length depending on the user’s locale.

Before translating the text I was tempted to avail myself of iOS’ ability to auto-adjust font sizes for a statically sized label.  I figured the sentence length wouldn’t vary so much and that an auto-adjusting font size could handle that difference.

I could not have been more wrong.  Doing so resulted in text so small that it was rendered unreadable and sometimes text that gets clipped off by the boundaries of the container label.

I learned, the hard way, that multilingual apps really are better off having multi-line labels with a fixed font size.

Going multiline however introduces a new problem.   It forces us to position controls spaced far enough from each other to compensate for the wordiest languages whose labels will expand the most.  Release 1 of KEYBOX followed this approach.  It worked for the most part but it took a lot of manual testing across languages to make sure the text was readable and that there were no overlapping elements.

I knew that I couldn’t take this approach forever and for release 2 I decided to change tactics.  I developed a high-level, goal-oriented layout utility class that lets me accomplish tasks such as “place this text field 10px under that label and center it on screen” or “left align this label 5px to the right of that icon”.  As a result I no longer have to consider the pixel locations of positionable elements across all locales at once and can focus more on the general look of the UI.  In some ways it works like HTML with the end result being one element following the last but unlike HTML it still retains simple, pixel perfect control.

 

Example:

KEYBOX 1 Without Dynamic Layout

KEYBOX 1 – Without Dynamic Layout

 

Keybox 2 import export

KEYBOX 2 – With Dynamic Layout (Text is directly under cloud image and the warning icon is to the left of the text)

 

I intend to open source this layout engine for those who want to maintain a professional layout for their multilingual apps but my best piece of advice would be to release one language at a time and just get your app out there first!  From there on, you can roll out new languages gradually.

How to Get the Local IP Address of an iPhone 4S

Posted on by

After a long 3 weeks of waiting, the iPhone 4S I pre-ordered has arrived and I’m in the process of thoroughly testing Release 2 of KEYBOX against it.

Today I have found what may be an issue with finding the local IP address of the iPhone 4S……. and a solution that worked for me.  KEYBOX has a built-in web server for exporting and importing backup files and it uses the IP address retrieval technique described in Erica Sadun’s wonderful book The iPhone Developer’s Cookbook to serve and accept these files.

In at least my case that technique is no longer usable for the iPhone 4S only.  The issue, as far as I can tell is that appending “.local” to a host name and attempting to retrieve the IP address via the gethostbyname function results in a NULL pointer to a hostent structure.  Removing the “.local” works but the IP address returned is not local and is not accessible from my Mac, as shown below.

Old gethostbyname

I could not reproduce this issue on my other iOS devices and googled until I stumbled upon the below alternative approach by Zach Waugh.

http://blog.zachwaugh.com/post/309927273/programmatically-retrieving-ip-address-of-iphone

Thanks to Zach, I am now again able to retrieve my iPhone 4S’ local IP address.  I have also tested this approach on my older iPhone 3GS and my 4th Generation iPod with positive results.

New gethostbyname

Hopefully I am alone in this issue but if others are experiencing it also, give this approach a try!

Amazon S3 Server Side Encryption Flawed

Posted on by

Amazon recently announced a new server side encryption facility for their popular S3 service.  It employs AES-256 to encrypt objects much the same way KEYBOX does with secrets on your iPhone.  In and of itself there is nothing wrong with this, except perhaps the marketing.

My biggest gripe with Amazon’s server side encryption solution is how they promote encryption as something best not done by the client.  They cite messiness and difficulty as reasons for this.

It’s Called Wiretapping for a Reason

The objects transferred to/from S3 should be encrypted end-to-end.  They traverse a wide array of devices on their way from the client to S3 including home Wi-Fi networks, ISP networks etc…  Each of which may be monitored.

The only way to be certain the objects are kept secure is to perform encryption on the client side before any objects make it out onto the network.  If HTTPS is available, it should be used to shuttle the data to S3  (I can find no indication that the objects transferred to and from their servers are encrypted en route, as in HTTPS).

The Value in Encrypted Storage

Once the objects are stored in S3 there still may be value in encrypting them.  Machines break, get hacked into, get confiscated by law enforcement.  If you need to encrypt data in the first place it’s a good bet you want to be able to provide guarantees that it’ll remain secret despite these threats and not being the true master of the physical machines in which this data resides.  From this perspective server side encryption as an additional layer of security is valuable.

Conclusion

Everybody knows security is hard.  To pretend otherwise is irresponsible.  Amazon should exercise more caution in how it promotes this facility and not try to convince developers that it’s a magic bullet for their encryption woes.  The old adage: If you want it done right you gotta do it yourself applies here.

Sites Folder in Lion Missing

Posted on by

A lot of changes have been made to Mac OS X in Lion, some of them good, some bad, some just confusing.  Like this one…

I noticed today that the Sites folder under each user account’s folder is missing.  Upon further inspection, it seems it must be generated by turning on “Web Sharing” under the Sharing icon within System Preferences and pressing the “Create Personal Website Folder” button.

Pressing this button creates the Sites folder and the button is altered to read “Open Personal Website Folder…” as shown below…

Sites folder creation

I hope this tidbit helps people experiencing the same confusion I was.

How do I price my software?

Posted on by

I found a great resource today for software developers struggling to figure out how much to charge for their hard work.

Ironically, the book, Don’t Just Roll the Dice: a usefully short guide to software product pricing, is free as a PDF download.

Neil Davidson is articulate and explains in simple terms the factors to consider when pricing your software.  It’s well worth the $10 Amazon is currently charging for it and I intend to compensate Neil for his insights.