Work in Progress: Choices for Mobile Development

Example “every day” app request:

Build me a “recipes” app that lets me browse resipes and take a photo of a dish and upload to Facebook App, Flickr account, Twitter feed, or Generic Server so it can later be displayed in a web view or another in-app view that gets refreshed after you get a “success” message back from the server that you uploaded to.

Right this second, I’d personally code it in Objective-C/Xcode first, then do a Java version for Android.

QUESTION: Given a bit more time and a chance to step back for a minute, which language, IDE, SDK should it be written in?

Near Term Technology Choices

  • Corona SDK
  • Objective-C in Xcode for iOS / Java in Eclipse for Android
  • AIR 3.1 for mobile, CameraUI
  • PhoneGap
  • Titanium

Corona SDK, media.Camera

Cons

  • As of 02.20.2012, lack of support for Web Services (REST, SOAP, etc) processing. So far just HTTP POST & GET and sockets.
  • 2.5D is not easy in Corona SDK. Trying to “fake 3D” or do 2.5D by scaling a physics body while animating it’s position doesn’t work out of the box, for example. Various hacks are required to fake it. While you’re resizing the visual graphic for every frame, collision detection is likely to get screwed up because the physics body’s collision bounding box doesn’t resize “on enter frame” after it’s been set once. This is a Box2D limitation, from what I’ve heard. In general, Corona is best for 2D content only, at least for the moment.

Pros

  • Holy shit! It’s so easy! If you have Actionscript experience (or Javascript application dev experience), Corona is a piece of cake. Feels easier than web Javascript (no DOM differences or old browsers to worry about). Here’s a Flash to Corona porting guide, their pitch to Flash Devs.
  • Has support for device hardware access to Camera (native Camera app can be call up) via media.show().
  • Has access to SQLlite.
  • No iAds support but has custom Ads framework with support for two ad networks.
  • Has built in Physics, Animation, Facebook, Analytics, JSON, In-App Purchases libraries.
  • Looks super approachable for the average AS3 developer. A bit more to learn for Front End devs who’ve never worked with sprite sheets, movieclips, easing equations, etc. Faster for Front End and Flash Developers to learn than learning about reference counting in Objective-C.

Objective-C / Java native, UIImagePickerController or AV Foundation framework / android.hardware.Camera

Cons

  • Building for iOS first (most likely). Will need to write separate Java version for Android. Two code bases to maintain.
  • Possible code base fragmentation between iPhone, iPad 2 and iPad 3, depending on how the app file size download limits issue plays out and whether. People are expecting x4 the pixels for iPad 3 high res display.
  • More dev time required

Pros

  • Closer to the metal, more hands on control of everything in the iOS / Android SDK. Fewer problems, re: lack of full native support in 3rd party mobile tools? (a.k.a. no need to find or write “native extensions”).
  • Cleaner code – just try opening up a published Titanium project in Xcode and take a look at the crap load of native code that converts JS to Obj-C included that would not be there if you built your app using native code in the first place.
  • A lot of clients, for the moment, seem very into iPads and iOS, more so than into Android (not a long term bet, considering Android’s market share, even with the hardware fragmentation).

AIR 3.1 for mobile, CameraUI and CameraRoll

Cons

  • Adobe’s sloppy management of the Flash platform was a highly frustrating and uninspiring series of events. Between the buggy releases of Flash IDE, Flash Builder and the Flash browser plugin, especially on Mac OS X, and Adobe’s bumbling PR fiasco re:HTML5, it’s belated focus on the Gaming market and it’s late introduction of Stage3D for mobile devices Adobe is not a company that inspires me with confidence when it comes to IDE’s and SDK’s for any kind of code.
  • Lack of full native support in 3rd party mobile tools? (need to find or write “native extensions”).
  • Need to super optimize AS3.0 code. Possibly at the expense of code clarity.
  • To get access to the Gyroscope and Notifications, you need to use a Native Extensions
  • Potentially unable to use some commonly used libraries, for example, if they’re not compatible with Starling framework (Stage 3D) etc. or if they’re likely to affect performance on slower mobile processors

Pros

  • There’s a legion of Devs with years of AS3.0 experience out there.
  • Tons of free resources all over the web.
  • I’m getting up to speed w/ Objective-C, have Java experience, how complex will it really be to write my own native extensions?
  • Possibility of a Single Code base for iOS and Android…

PhoneGap

Cons

  • Adobe…
  • Lack of full native support in 3rd party mobile tools? (need to find or write “native extensions” ?).
  • Will still require lots of conditional code / State design pattern to account for platform specific features as well as iPad v. iPhone, standard display v. high retina display, etc.

Pros

  • PhoneGap has some elementary access to the iOS camera (at least).
  • More developers know Javascript, HTML, CSS or at least, those are easier to pick up than manual “reference counting” in Objective-C
  • Support for Web Services via Javascript, examples in their wiki.
  • Possibility of a Single Code base for iOS and Android…

Titanium

Cons

  • Lack of on device debugging in the FREE version of Titanium IDE itself. Looks like there’s a 3rd party tool that might work.
  • Incomplete documentation in Titanium’s API docs. For example, as of 03.19.2012, the Filesystem API doesn’t document methods like mimeType(), which is nontheless included in the Kitchen Sink’s filesystem.js example.
  • Lack of full native API support. Need to find or write modules for certain native features.
  • Will take months for Titanium to be updated for features in every new native OS release (like it did with the iOS 5 release).
  • Will sometimes still require lots of conditional code to account for platform specific features as well as iPad v. iPhone, standard display v. high retina display, iOS v. Android, etc. Perhaps, this is not a surprise, since for Universal apps in Xcode one sometimes has to create separate Views or .xib files for Universal apps, one for iPhone, one for iPad.
  • Titanium IDE was super buggy on my OS X 10.6.8 machines at work and home. SDK 1.8.2 seems to have fixed these issues.

Pros

  • A reasonable level of Memory Profiling is possible for Titanium apps using Xcode’s Instruments.
  • Titanium offers you access to your device’s built-in basic camera app (UIImagePickerController on iOS), but it looks like a lot of the Titanium.Media camera related methods are iOS-only.
  • Enterprise-level support available, which Tech / IT Directors in charge of larger projects will find appealing.
  • Titanium allows developers to write their own modules, if Titanium itself is missing native features. There’s an iOS Module Developers Guide. For example, Titanium doesn’t support the iOS AV Foundation framework, the one that allows you to write your own custom Camera or Video application (as opposed to using UIImagePickerController, etc). Here’s a Titanium AV Foundation module written by a dev on GitHub (free, open source, under Apache License 2.0).
  • Has a Web Services (SOAP) example in it’s demo Kitchen Sink app. More developers already know Javascript.
  • Has iAds support. Possible to use other networks, like AdMob, through plugins/extensions (write yourself or get from their Open Mobile Marketplace)
  • Possibility of a Single Code base for iOS and Android…
Advertisements

Random Notes to Self on Cocos2d Basics

  • Under the Cocos2d coordinate system (0,0) is at the bottom left, like in Core Graphics (vs Flash & standard UIKit, Animation with the upper left)
  • Cocos2d offers convertToGL and convertToUI methods to switch between UIKit and Cocos2d coordinate systems
  • In Cocos2d each new screen is a Scene. Scenes have Layers, Layers have Sprites
  • iPad screen size 1024×768, iPhone 320×480 (460 if you count the status bar). Note the distinction between pixels & points used in iOS dev.
  • Layers act kind of like layers in an .fla, with multiple Sprites per Layer (not the greatest practice for .fla). In a way, each layer is a bit like a Display List of its own
  • Layers have an addChild method with one of the input params being “z”, which works exactly like the z-index in CSS concept or the Display List’s depth order in AS3
  • ‘#import “MyLayerClass.m”‘ causes “Apple Mach-O Linker (Id) Error”. Just fix the import statement to point to a “.h” file instead of “.m”
  • a fun way to get the dreaded EXC_BAD_ACCESS error is to forget to include a “return self;” statement in an -(id)init method for a Layer or Scene class

Note to self: “@protocol” in Objective-C is like an implementable “interface” in AS3.0 or Java

Here’s a quick example. Perhaps, before trying to decipher the grey code boxes, scroll down a bit to this section:

  • The protocol specification is quite simple. it is basically @protocol ProtocolName (methods you must implement) @end.
  • To conform to a protocol, you put the protocols you’re conforming to in <>’s, and comma separate them. Example: @interface SomeClass <Protocol1, Protocol2, Protocol3>

Objective-C for AS3.0 Developers: How to automate getters & setters

In AS3.0 we sometimes have to type a bunch of repetitive lines of code to create Getter & Setter functions that look like this:

protected var _property1:String;
protected var _property2:String; 
//...
public function set property1(p1:String):void { _property1 = p1; }
public function get property1():String { return _property1; }
public function set property2(p2:String):void { _property2 = p2; }
public function get property2():String { return _property2; }
//...	

There’s a shortcut in Objective-C.

If you want, you can manually write out getter & setter methods. It might be useful for those who prefer clarity more than using code shortcuts. However, in this example, the lines that start with @property in the header file and @synthesize in the implementation file allow you to skip the often tedious task of typing up Getters & Setters:

//MyClass.h file
@interface MyClass: NSObject
{
    int *property1;
    int *property2;
}

@property(nonatomic, readwrite) int *property1;
@property(nonatomic, readwrite) int *property2;

//...
@end

//MyClass.m file
@implementation MyClass

@synthesize property1;
@synthesize property2;

//...
-(void)dealloc
{
    [text release];
    [super dealloc];
}
@end

An example from UIKit framework

@property calls are listed in the iPhone equivalent of the asdoc (AS3.0 api documentation). In this case, for a class called UIImageView, and it’s property animationRepeatCount, the documentation lists:

@property(nonatomic) NSInteger animationRepeatCount 

Which means you can use setAnimationRepeatCount as the Setter method for animationRepeatCount whenever you have a variable of type UIImageView. Here’s a video tutorial that uses the setter for this property.

You can also see @property calls in the UIImageView.h header file in the SDK folder on your machine. The path is something like:
YOUR_HARD_DRIVE/Developer/Platforms/iPhoneOS.platform/
Developer/SDKs/iPhoneOS3.1.3.sdk/System/Library/Frameworks/
UIKit.framework/Headers/UIImageView.h

Objective-C for AS3.0 Developers: How to create a new object

In AS3.0 you create a new Object, or instance of a Class, and store it in a reference (or variable) like so:

private var myRef:MyClassName = new MyClassName();
private var myRef:MyClassName = new MyClassNameSubclass();

In Objective-C 2.0, there’re several ways to do this.

Here’s 1 way:

MyClassName *myRef = [[MyClassName alloc] init];

Here’s another:

MyClassName *myRef; //create the reference/variable
myRef = [MyClassName alloc]; //allocate memory of size MyClassName
myRef = [myRef init]; //initiate the MyClassName instance called myRef

And another:

MyClassName *myRef = [MyClassName new];

Why do we have to bother allocating memory manually? AS3.0 developers should be familiar with the concept of Garbage Collection. Objective-C does support GC but not everywhere. For example, the iPhone doesn’t allow it, apparently because of concerns over battery life.

In case you’re wondering, alloc and init are methods inherited from NSObject. Most Objective-C classes in the Foundations Framework inherit from NSObject.

Objective-C 2.0 also allows for dot (.) syntax that Flash/Flex/Actionscript developers are used to.

However, it seems like object instantiation doesn’t fully work with dot syntax. I’m no expert but when I try to write “MyClassName.alloc()” or “MyClassName.alloc” I get errors.
This worked, however:

NSAutoreleasePool * pool = [NSAutoreleasePool alloc]; 
pool = pool.init; 

/*
MyClassName *myRef =  [MyClassName alloc];
myRef = myRef.init;
*/

I’m guessing this means that dot syntax works with Instance methods but not with Class methods.

Confused

Reading Programming in Objective-C 2.0. It’s pretty good overall. Easy to read, the explanations usually make sense. Here’s 1 part that didn’t, p. 50:

For example, it’s guaranteed that an integer value will be stored
in a minimum of 32 bits of storage. However, once again, it’s not guaranteed.

Granted, may be I’m just being dumb, but context doesn’t seem to help either:

You should never write programs that make assumptions about the size of your data types. However, you are guaranteed that a minimum amount of storage will be set aside for each basic data type. For example, it’s guaranteed that an integer value will be stored in a minimum of 32 bits of storage.However, once again, it’s not guaranteed. See Table B.2 in Appendix B,“Objective-C Language Summary,” for more information about data type sizes.

The Table in the Appendix says stuff like: “Integer value; that is, a value that contains no decimal point; guaranteed to contain at least 16 bits of accuracy.” Again, it says
“guaranteed” but the paragraph above says both, “guaranteed” and “not guaranteed.”