Posts Tagged ‘iPhone’

Page width problems on iPhone Safari – solved!

I was having a bear of a time trying to figure out why a web page was showing up too wide in Safari mobile today.  I thought everything was set up fine:  I had the meta tag to set the viewport to device-width, and the scale to 1.0, etc.  So I figured it was some element within the page that was somehow erupting from the bounds of the body element…but it was in fact the body element itself (and the html element) that needed some attention.  Make sure to set the body and html elements’ width and max-width CSS properties to 100%!  Problem solved.


Project Name Generator is a GO!

There is much wootage on this day.

I submitted my first iPhone app, Project Name Generator, to the App Store a couple of days ago. At around 1:30 pm today I received a message from the iTunes store that it had passed review and was “Ready for Sale”. About an hour later it was available in the App Store!

Now I just need to market the thing.

ProjNameGen: There are many like it, but this one is mine.

There are tons of random project name generators out there, but surprisingly few for the iPhone from what I can tell.  That’s where ProjNameGen comes in.  I spent an extremely frustrating but ultimately rewarding weekend bashing my head against my keyboard and threatening to cast off all trappings of technology and join an Amish village somewhere learning about Sqlite, honing my Objective C skills, and navigating the incredibly quirky and unfriendly XCode IDE.

The bulk of the app is done.  It makes random project names based on word lists for the first second and third words.  Right now the first word is always an adjective.

The little heart icon in the top right is for marking a project name as a favorite, and I haven’t coded up the functionality for that yet.  I’m thinking about making it a simpler icon – white with a punched-out plus sign so it goes with the minimalist feel of the app.

The Settings tab will have a few things for the user to play with.  You’ll be able to add your own words and enable/disable the first/second/third words.

The space at the top will be for advertising.  I’m going to document my upcoming struggle to get this thing into the app store.

My Doodad-A-Week Project

Pretty simple plan: Make one game a week. Inspired by such projects as Game-A-Week and Thing-A-Week, I decided this will be a good way to get off my butt and start learning the various technologies and techniques I need to.  I was nudged into it by this post on Smashing, as well as recent events and the coming new year.

And I don’t plan on limiting this to just video games.  I’m going to make some board games; pencil-and-paper RPGs; games of skill involving household items.  Anything goes!

The technologies I plan on learning/using are:

  • Silverlight 4
  • Flex 4
  • jQuery
  • YUI
  • Lots of CSS
  • GameMaker
  • BlockLand
  • ASP.Net MVC
  • Python

…and whatever else that catches my fancy.

Micro-Rant: I’m sure a lot of my focus will be on mobile web games.  It’s a market that is woefully underdeveloped – just look at Apple’s mobile web games page.  I think Apple doesn’t emphasize web games/apps because they can be used by anybody with a browser.  And as much as I love their stuff, Apple is all about proprietary.  Notice there’s no Flash on the iPhone?  It’s not a technology issue.  It’s because once an app or game is written in Flash, it’s available to all platforms with little or no additional coding.  So what incentive would a developer have to write something in that god-awful Objective C and Cocoa mess if they could do it in Flash and have it available everywhere? End of Micro-Rant.

Oh by the way, I’ve ditched platform-specific mobile app design in favor of browser-based mobile apps.  We have a little ledger web site I built a few years ago where we keep track of our spending, and converting it to a mobile version was total cake.  I was using it as a test project to learn native iPhone development, but decided I was wasting my time learning something that was so proprietary.  As far as I’m concerned, coding in Objective C is like going back to punchcards – except that the punchcards are wet and you have to punch the holes with a dull pencil that’s held in your teeth.  It’s the least-convenient language I’ve actually tried to learn.  But I have two really great books on iPhone development, though, if anybody’s interested!

I don’t know how long I’ll continue the project, but I’m sure I’ll take breaks and work on more involved projects here and there.  I should make Hauler my first release, as it should only take a few hours polish it up and get it playable.

Edit: I’m expanding the scope of this endeavor.  It was originally just Game-A-Week, but I’d like to not be limited to games.  I have a lot of little tools and handy things I’d like to build and this weeklong development cycle is perfect for them.

Cocoa/Objective C development tips for .Net Folks: Part I

No, this isn’t about using .Net to make iPhone apps!  It’s just a set of observations that might make it easier for people like me who currently use .Net (specifically, ASP.Net) at work, but want to start fiddling around with some Objective C, Cocoa, etc.

Keep in mind that this is from the perspective of someone who got into web development without traveling down the formal education route (when some of my buddies were learning C, COBOL and PASCAL in CompSci 101, I was sucking sand through a gasmask, patrolling some godforsaken ammo dump or airfield in the middle of nowhere).  I have no pure C language knowledge or insight, so all of this stuff is new to me.  I know many web developers in the same situation, so maybe this will help some people make the connections between Obj C and the types of languages they’re used to.

– “Actions” are event handlers.
– “Outlets” are properties that can be bound to your user interface widgets.  They are objects of the same type as the given widget. So if you have a RoundedButton on your UI, you’ll probably have a RoundedButton in your .h/.m code if you want it to actually do something.

From what I can tell, you don’t need to name the specific buttons in the UI part…you associate the button with its corresponding outlet via a drag-and-drop in the UI editor (“Interface Builder”).  I’m pretty sure you can do it manually/dynamically via code, too.  In the .Net world, you’d set the name of the button in the UI editor or in your HTML code, and Visual Studio would automatically make the corresponding code additions.  I haven’t seen that ability in XCode/Interface Builder, but I’m totally new to this so don’t take it to mean that it doesn’t happen.

You can think of the .xib file (known as a “nib” file by Cocoa vets to honor the former file extension) as needing a code-behind page.  The nib is your UI, and the .h and .m files need to be told “Hey, I have these do-dads on the UI.”  After all, if you dig through the code that ASP.Net automatically generates, you’ll find the same kind of definitions for each UI item in the code-behinds.  Same-same.  Don’t let the EXTREMELY WEIRD BRACKET-HEAVY SYNTAX scare you.

Speaking of which, here’s a brief bit of learnin’ about the syntax.  Let’s take apart this function…

-(IBAction) openThing: (id) sender
// code that does stuff

The hyphen is there on purpose.  (Don’t ask me why.)  (IBAction) is the return type, openThing is the name of the function.  (id) is the type of the argument and sender is the argument itself.  To call a function, use brackets like this:
[myObject doSomething:5];
myObject being the object, doSomething is the function being called, and 5 is the argument.

By the way, the “id” type in Obj C corresponds to Object in our world.  It could be anything.  You’ll need to cast it to whatever type actually sent the event if you want to use it.

If you ask me, the brackets clutter up things, and dot notation isn’t supported enough in Objective C.  They added it to 2.0, but I think it could be used more than it is.  You still need to use brackets for functions if I’m not mistaken.  Of course, you can’t just change the entire syntax of a language without peeving your developer base!

On a side note, I’ve found XCode to be a sweet IDE to work in.  At first I found it a little annoying to have to switch between two completely separate programs to do coding vs. UI work, but then I realized some benefits to it.  Unlike Visual Studio, you can open up just the stuff you want to work on.  VS gets more bloated and resource-hoggy with every iteration, and it would be nice if you could completely rip out the Design mode when you’re working on ASP stuff.  You know it’s lurking in memory somewhere, ready to reformat your clean, hand-written tags the moment that you accidentally summon it.

Another advantage to having two separate programs is that it reinforces the separation of concerns between code and UI.  This premise lies at the very heart of how iPhone programming works – it uses the Model-View-Controller pattern!  I have used this pattern extensively, and although I’m not a design patterns guy, I have to say that it makes for fairly clean distinctions between the various pieces in an app.  If you haven’t used it yet and you’re an ASP.Net developer, you’re in luck.  ASP.Net has an official MVC implementation!  Grab it, build some stuff with it.  Understand it. It’ll help you see how things work in the iPhone (“Cocoa Touch”) world.

The books I’m reading on the subject are Beginning iPhone 3 Development by Dave Mark and Jeff LaMarche, and Programming in Objective C 2.0 (2nd Ed.) by Stephen G. Kochan.  I’ve found both of them to be very, very good books.  I will say that getting about halfway through the Objective C book first will make your life a lot easier.  I’m currently switching back and forth between them.

I’ll be posting more stuff as I wrap my head around this.