Tag Archives: ipad

Make your iOS apps support public types (like .zip)

It will happen once in a while, when using an iPhone or iPad, a person may get an email with an attachment to be opened, but can’t because there is no app on the device to open it. Or similarly, surfing the web using the Safari mobile browser, and suddenly there is a file to be accessed/downloaded but it isn’t supported in Safari on iOS.

And for app creators/developers, we solve this issue by allowing our apps to open those types of files, to make up for the lack of Apple having an app that does so.

There is much info around the internet about this, but mostly the info is about supporting custom file types (for random example: .my3dimage) it all comes up short for supporting public file types. I mean, types of files that are out there in the world, but the iPhone doesn’t have an app that supports them. A really obvious case is PDF files.  They used to be not supported, but now they can be viewed in Mail or Safari.  One popular type that is not supported in mail or is the zip file type.

An app developer simply adds the CFBundleDocumentTypes key to the app’s Info.plist file, and fills it in with info, and then builds the app to handle the file when another app tries and fails to open a file.

CFBundleDocumentTypes is an Array of Dictionary objects. Each dictionary has a set of keys (and values) and following is a list of recommended keys from Registering the File Types Your App Supports in Document Interaction Programming Topics in the iOS developer library:

CFBundleTypeName specifies the name of the document type. (ie. Zip archive)
CFBundleTypeIconFiles is an array of filenames for the image resources to use as the document’s icon. (could be a picture of a folder with a zipper, like Windows Explorer uses, or anything else)
LSItemContentTypes contains an array of strings with the UTI types that represent the supported file types in this group. (an array of the UTI types.. this is the confusing part for quickly supporting public types that I deal with in a moment).
LSHandlerRank describes whether this application owns the document type or is merely able to open it. (This is another interesting part that I talk about)

More can be added (and SHOULD be added), and they’re found in Table 2 Keys for type-definition dictionaries, of the CFBundleDocumentTypes section, in the Core Foundation Keys page of iOS Information Property Key Reference.  But BEWARE!  Several of these keys are not for iOS, but Mac OSX, and some are deprecated, while still remaining in the list.

There is more information on the meaning of each specific value that can be assigned to each key. Check out below Table 2, in CFBundleDocumentTypes section, for Document Roles and Document Icons.

After Document Roles and Document Icons sub-sections, is a relatively section of some importance, Recommended Keys.  I say “some” importance because it’s a very important section naturally, but contains out-of-date recommendations.  This list contains 1 valid key for iOS and 3 that are Mac OSX only, plus those 3 are deprecated:

LSItemContentTypes
CFBundleTypeExtensions (not in iOS)
CFBundleTypeMIMETypes (not in iOS)
CFBundleTypeOSTypes (not in iOS)

The following are strongly recommended, but optional:

CFBundleTypeIconFile
CFBundleTypeName
CFBundleTypeRole

These 7 recommended keys, partly overlap with the 4 I listed above from the Registering the File Types Your App Supports section. The overlapping items are:

LSItemContentTypes
CFBundleTypeName

It can be confusing then, which to use… I think this is just a case of some instructions not being updated with the latest best-practices. So try support as many non-deprecated keys as possible!

Now for a list of the strings that can go into the all-important LSItemContentTypes section:

System-declared Uniform Type Identifiers (UTIs)

 

The table on this page lists a whole bunch of system and public file types that aren’t necessarily supported in the iPhone or iPad.  Zip is in the list, and happens to have the com.pkware.zip-archive valiue.

I won’t discuss the icon, but please see Document Icons  within Custom Icon and Image Creation Guidelines for info about them.

Info about the Role is in iOS library.

There is a possible issue with the Rank, if two apps declare themselves as the Owner of a type, then one of them is given precidence for the button that appears on the right-side in Mobile Safari, as seen in this picture:

 

 

 

 

 

 

 

 

 

I don’t know much about dealing with this yet, but it should not be a huge problem because a user can click on the “Open In..” button and see other apps that open it, like in the following picture:

Hope that helps someone.

2 Comments

Tablet screens: Playbook vs Galaxy Tab vs iPad

This is just a bit of technical numbers trivia.
I made these calculations to have a reference for comparing things.

Platform

BlackBerry
Playbook

Samsung
Galaxy Tab
Apple
iPad
Resolution
(pixels)
1024 x 600
1024 x 600
1024 x 768
Diagonal size
(pixels)
1186 diag
1186 diag
1280 diag
Diagonal size
(inches)
7"
7"
9.7"

pixels-per-inch
(dots per inch)

169 ppi/dpi
169 ppi/dpi
132ppi/dpi
App icon width (pixels)
90px
(90 x 90)
72px
(72 x 72)
72px
(72 x 72)
(divided by ppi)
169 ppi
169 ppi
132 ppi
App icon width
(inches)
0.53"
0.43"
0.55"
Leave a comment

A case of settings separation – NSUserDefaults to app and user settings

The work of a software developer can be fun, but can also be very monotonous.

This iPhone game-app that I’m developing has its glorious moments, like when I finally got the first sound effects in and they gave a whole new level of excitement.

Then there are days like the last couple weeks when I’ve been designing and building the game menus.  These moments are full of dark, frustrating moments, with the odd ray of sunshine.

A few minutes ago I felt one of those sunshine rays!

The moment came when I created a single new property of my project’s main class.  Until this moment, I had an object called userDefaults, being an  NSMutableDictionary.  I had been using this with the iPhone SDK’s NSUserDefaults shared instance (standardUserDefaults message).  Thus I had named my object “userDefaults”.

Yet I was feeling uncomfortable with this, because I have various levels of information that I want to save when the user ends a game-play session/level/round, etc… and also when a user quits the app.

Now I believe there are methods to use NSUserDefaults with great efficiency.  I haven’t gone through the guides and experimented.  Right now, I’m more interested in Core Data for information management.  But, I haven’t gone through Core Data either.  There are many different ways to store data, and I’m not going to devote any more time, beyond what I’ve spent already, to learning better ways before I launch my app, because I’m not working on something with thousands of values, that need to be accessed quickly or changed in complicated ways.  So loading and saving property list files seems sufficient for this development time.

All I have are my trusty methods I’ve written that load, save and delete structures to property-list files.

But it came to the point of being unsure how to organize the values into dictionaries or arrays, and if the information for one player files should be saved in a file separate to another file for another player, or combine the player data into a single file for one set of information.  That’s a bit abstract… sorry.  What I mean is, … I got confused.

So I went through the code for managing the game settings, and somehow just thought up this idea:  app settings.   Up until now, I’ve been calling all settings under the umbrella-term “user defaults” or “user settings”.

Now when I see the two words “app settings”, I was able to understand a new level of separation.  Simple, it seems so obvious now, why didn’t I think of it before?  I suppose because a lot of problems are solved by coming up with new, better names for things.  Going into a paint store and asking for a can of blue paint could lead to a thousand different choices.  Asking for cobalt blue really helps.

All my settings that are not user-specific will be called app settings, and the user specific settings … are going to be saved as files separated by player account.  That gives me a LOT of mental clarity for the next few hours of work.

1 Comment

Documentation and 3D game engines

I am progressing slowly but surely. The 3d rendering engine for the iPhone that I am using is called SIO2. I am finding it slow going because the documentation is not what I call good. There are no step by step procedures in the tutorials and the reference doc materials are very raw, with no clean summaries,except those on the front page of the website that describe, in point form, the most general capabilities. Those capabilities are great,but after putting in the time to download the engine and try out the tutorials, I am coming to a question: is a pre-existing system better than developing a system in-house, if the existing system is so time consuming that the learning curve is almost as long as the development process?

Here I am frustrated with the lack of good quality and complete learning materials, but the existence of the system is still better than developing my own system. That is because in the time it would still take to devlelop my own thing, the existing thing may (or may not) improve, and in other cases I may find some help that I had not found at first. So the learning of an existing system is better.

This experience is going into the heaping pile of experiences of bad documentation for products I have seen. There is a wiki, and I might start contributing to it.

Going forward in the future, the skill to produce good documentation may become a very valuable transferable skill in the workplace. It seems very boring in some product contexts, ie. Vacuum cleaner manuals, software application manuals, inflatable air matress instruction sheets. Yet this world needs a better, universal, written method of learning that appeals to the reader. Something like google’s API doumentation, and apple’s iPhone and iPad documentation.

Leave a comment