Romain Nurik posted an excellent article today on why you need to hand edit layouts for Android rather than using a WYSIWIG tool

First off, there will be some obvious bias in this post. I have been very fortunate in my working career to work with some truly great product managers, designers and artists on mobile applications and so for the benefit of the app consuming public none of my frankly brilliant crap UIs have ever seen the light of day. I do however still look forward to the day where by I can put a cheat mode into one of our own applications that resorts to developer place holder graphics! Some great examples of what games look like before an artist breathes on them can be found on this thread at Toucharcade

If you take the same view point as me, that to make a truly decent user experience for a given platform especially on mobile,  then you need to understand the technicalities and nuances of developing for that platform. A great example of this would be the difference in the back metaphor on various devices,  on Blackberry and Android you have a dedicated back button, iOS the use of UINavigationController and for Java mobile devices the use of soft keys and context menus.

Knowing these interface cues is why there needs to be a close interaction between developer and designer. It makes sense if a fast utility application is required to make  sure standardised controls of the platform are used where possible  (ie ContextMenus on Android vs UIActionSheet on iOS vs Softkey driven menus on Java based devices) otherwise a lot of development time can be expended on making custom UI controls that may or may not be necessary, if all stakeholders are aware of what components are available on a given platform. For this reason alone it is worth at least having a WYSIWIG  editor so that designers who may be new to a platform (Java MIDP2 is younger than publishing to the web, and Android, iOS, WebOS are relatively new, let alone the even newer platforms mobile designers will have to contend with in the future ie Meego, Bada etc etc) have the ability to experiment with the UI widgets that are available for a platform and produce mockup guis that a developer can then bring to life!

The other area where at least having a fast preview of changes to the UI code is where a WYSIWIG editor can really help, or at the very least a very fast way of previewing on a decent simulator, in fact it has to be said MicroEmu perhaps leads the way here when it comes to very rapidly changing screen sizes

Where both Android and iOS have succeeded in my view is that they have made the information on what designers have to work with is far more readabily accesible. A simple Google search for icon design guidelines for three popular platforms will tell you a lot, bearing in mind with the current trend of app stores the icon is the first piece of information that you are likely to convey to your user therefore it pays to have the perfect dimensions. For example try the following searches

“Blackberry icon sizes”

“iOS icon sizes”

“Android icon sizes”

“Nokia icon sizes”

Having to dig for this sort of information is what in the future will infuriate both developers and designers as new devices, screen sizes and user interactions are released into the market

Therefore until Android becomes as set in stone as HTML/CSS I don’t believe many designers have the time to teach themselves another XML based layout manager and need to work closely with developers and hopefully have some sort of ability to experiment with UI metaphors without a developers assistance. This is something which a WYSIWYG tool whilst most likely constrained to a single resolution at least provides. Once this point is reached, much like a sane server admin will never let a developer loose on production infrastructure without supervision, a designer will not let the developers near the UI without their guiding light

However until that day I concur with Roman a hand coded UI will be superior this is still true even with WYSIWIG tools such as Interface builder on iOS

• Icon.png – Home screen icon for iPhone 3 (57×57)
• Icon@2x.png – Home screen icon for iPhone 4 (114×114)
• Icon-72.png – Home screen icon for iPad (72×72)

• Icon-Small.png - Settings/Spotlight icon for iPhone 3 (29×29)
• Icon-Small@2x.png – Settings/Spotlight icon for iPhone 4 (58×58)
• Icon-Small-50.png – Spotlight icon for iPad (50×50)

• iTunesArtwork – Icon for iTunes AdHoc distribution (512×512)

http://android-developers.blogspot.com/2010/06/future-proofing-your-app.html

The aapt tip for dumping out what features your app requires was certainly new to me!

For anyone who is not aware or newer to Android, I always feel the need to highlight the Draw 9-patch technique as something that  will help immensely when dealing with differing screensizes, and I am sure those that are using vanilla UIImage on iOS devices will come to envy in the future when supporting multiple screen sizes in an easy way that does not require code changes.

The following session video from Google IO on supporting multiple handsets almost goes into far too much detail and makes this problem space seem much harder than it actually is! However I and as am sure many, fully appreciate the highlighting of potential pitfalls that we may run into, rather than having to discover some of these hazards at some point through the development cycle of an application!

For those envious iPhone developers of NinePatch images you may wish to check out the following project http://blog.tortuga22.com/2010/05/31/announcing-tortuga-22-ninepatch/

Steve if you believe replied to emails sent stating

“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

Far greater than how something has been written is the problem of shovelware, whilst it allows the store to quote very large numbers of applications compared to the competitors of the app store, how many companies are submitting multiple applications every day of debatable quality or at least that could be combined together. Some of the worst offending companies have been removed from the developer program

So ignoring the arguments on whether what Apple is doing with the new terms in the sdk agreement is right or wrong and what effect it has on native cross platform app development. I was thinking what else they could do for the submission process for their platform if the stated aim is simply to raise the standard of apps, regardless of how they are produced.

One of the reasons for me that the app store has been a success for developers, has been how much easier it is to make an application available to the paid market globally, unfortunately this has meant the friction barrier is so low, that it allows for shovelware to be a positive revenue generating tatic. Thankfully this is actually quite an easy one to stop by implementing a cost barrier like Palm have on their app catalog, quite simply if you wish to make an application available there is a $50 cost. This simple barrier to entry means if the developer doesn’t believe their application is going to return at least $50 they will be unlikely to submit it or burn through cash and be stopped that way.

Theres a great set of videos explaining buffer overflow attacks starting here
with a hands on demo of return to libc hacks here

Available on iTunes:

http://bit.ly/knowcolor

Amazing how after a few days away from the computer at Xmas can lead to inspiration for a small game, so after I had decided it had been too long since I had made a little fun game and as I wanted to play this myself! I got started, a few days later Know Color was born!

Subsequent posts will show the early stages of this game before there was any artwork and it looked very very different, and some notes on porting this game concept to other platforms.

The app store approval time was truly amazing, with this game being made available for sale 24 hours after submission, so thank you Apple!

For now though here is an app description and some visuals of the game:

Prove you’re smart and know color. Can you beat the Professor and your friends?

A game of speed and skill where you have to select the correct option matching the Professor’s instructions as quickly and accurately as you can. Post your high score to Facebook and Twitter and dare your friends to beat you! Who is the smartest of you all?

In 50 seconds score as high you can, you score one point for each correct answer but will lose 3 points if you answer incorrectly so be careful!

View a video on YouTube:

You can find some images of the game here

http://www.cocos2d-iphone.org/about

Features include

• Scene management (workflow)
• Transitions between scenes
• Sprites and Sprite Sheets
• Effects: Lens, Ripple, Waves, Liquid, Twirl, etc.
• Actions (behaviors):
  • Trasformation Actions: Move, Rotate, Scale, Jump, etc.
  • Composable actions: Sequence, Spawn, Repeat, Reverse
  • Ease Actions: Exp, Sin, Cubic, etc.
  • Misc actions: CallFunc, OrbitCamera
• Basic menus and buttons
• Integrated physics engine (both Box2d and Chipmunk)
• Particle system
• Text rendering support (variable and fixed width fonts)
• Texture Atlas support
• Tile Map support
• Parallax scrolling support
• Sound support
• Streak Motion support
• High Score server (Cocos Live)
• Touch/Accelerometer support
• Portrait and Landscape mode
• Integrated Pause/Resume
• Fast Textures:Supports PVRTC textures, 16-bit textures and 32-bit textures
• Language: objective-c
• Open Source: Compatible with open and closed source projects
• OpenGL ES 1.1 based

Once you have checked out the latest version from here like so

svn checkout http://cocos2d-iphone.googlecode.com/svn/trunk/ cocos2d-iphone-read-only

navigate to the directory cocos2d-iphone and run the following

. ./install_template.sh

This will install the cocos2d template into xcode for you, which makes setting up and using this framework even easier!
Great demos are available from within the project itself to learn from as well as the wiki documentation which can be found here

• Hello World
• Hello Actions
• Hello Events

Some full open source examples are available from the following links

• Tweejump
• Gorillas
• Thrown
• Grabbed

The greatest part for me personally is the heavy lifting that chipmunk can do for you regarding collisions and physics for your game, the best tutorial I have found for using it is available here

http://www.alexandre-gomes.com/articles/chipmunk/

http://corporate.scoreloop.com/

Provides location aware global high score boards

Ability to post to notifications to Facebook

Issue player challenges

Cross promotion of other games in the score loop system

Example game Wild Solitaire http://linktoapp.com/wild+solitaire

http://www.openfeint.com/

Compare games with friends

Location based scoreboards

game profiles

Achievements

Example game: http://linktoapp.com/alex+the+fox

http://plusplus.com/

Plus Plus is NGMocos private version of the above tools, they do intend to make it open in the future however

Example game: http://linktoapp.com/eliminate

When you want to have an application that starts up in Landscape without a status bar
the following code snippit placed into your applicationDidFinishLaunching method of the app delegate will allow you to test in the emulator!

//For your normal application execution on the iPhone, this can also be done in the info.plist
[[UIApplication sharedApplication] setStatusBarOrientation:UIInterfaceOrientationLandscapeRight];

//How to make the simulator behave itself preprocess for just the simulator
#if (TARGET_IPHONE_SIMULATOR)
UIScreen *screen = [UIScreen mainScreen];
tabBarController.view.bounds = CGRectMake(0, 0, screen.bounds.size.height, screen.bounds.size.width);
tabBarController.view.transform = CGAffineTransformConcat(tabBarController.view.transform, CGAffineTransformMakeRotation((M_PI * 90 / 180.0)));
tabBarController.view.center = window.center;
#endif

tabBarController in this case is the first view controller given to the window

Hope this helps someone else!

pretty indispensable in my opinion

http://www.ideaswarm.com/products/appviz/