#ios programing

foldedpaperboat:

In the ‘Hello, World!’ iOS tutorial, the app will display a string of white spaces with the provided code:

if ([nameString length] == 0)

i.e. if the user enters a <space> in the text field, the above statement will be false and the app will show: “Hello,  ”.

To check for white space, I’ve found  you have to trim nameString when it is declared using the NSString methods.

NSString *nameString = [self.userName stringByTrimmingCharactersInSet: [NSCharacterSet whitespaceCharacterSet]];

thelynchpinwithin:

It’s not too long back that  HTML5 was heralded by mobile app developers as the “technology” which could revolutionize ( read make it easy) the creation and deployment of mobile apps.

However, this was dealt a major blow and lot of press ( unnecessary?) when the first major brand to come out publicly against using HTML 5 was Facebook who used HTML 5 and then went native ( Objective C) with their newest FB app for iOS.

Fact: The native app works much better , renders faster and is an overall better experience from a UI perspective.

Tobie Langell describes the issues that FB was facing with their mobile app here. It is a detailed read.

In short here are the issues:

Tooling: The lack of developer api’s to track memory problems. Given the enormous number of images and posts on a infinite scrolling timeline,the RAM needs to function at a much more optimum level.  Or else the application starts to exhaust the hardware capabilities of the device thereby leading to systemic crashes. To manage this optimum performance we need to track the memory device via api tools. The lack of tooling in mobile browsers makes it difficult.

Infinite Scrolling: With HTML5 and JS, the infinite scrolling feature of Facebook’s Timeline is slower and sometimes incomplete. 

GPU: The API for the GPU is still clunky and it does not give the necessary acceleration. However, given the size of GPU buffers to the size of content consumed on mobile devices it would take a long time for a mobile browser alone to manage the GPU. Hence need for an API which can accelerate the content.

No doubt at the present moment Objective C sounds like a better bet to code on native, given the rather nascent innovation that has happened in the world of HTML 5. Also Native code (Objective C) will always run faster than a combination of HTML and JavaScript. But over time, mobile hardware will become faster and this difference that we see today in performance, will be less experienced.  

Moreover, HTML5 offers a “write-once, deploy everywhere” advantage that can be a huge benefit for many mobile app developers in the future as more screens clamor for our attention.

I don’t think we have heard the last of this debate. Would be nice to see how it unfolds over the next few years or shall we say the next few apps ?

J2ObjC is an open-source command-line tool from Google that translates Java code to Objective-C for the iOS (iPhone/iPad) platform. This tool enables Java code to be part of an iOS application's build, as no editing of the generated files is necessary. The goal is to write an app's non-UI code (such as data access, or application logic) in Java, which is then shared by web apps (using GWT), Android apps, and iOS apps.

J2ObjC supports most Java language and runtime features required by client-side application developers, including exceptions, inner and anonymous classes, generic types, threads and reflection. JUnit test translation and execution is also supported.

J2ObjC is currently between alpha and beta quality. Several Google projects rely on it, but when new projects first start working with it, they usually find new bugs to be fixed. Apparently every Java developer has a slightly different way of using Java, and the tool hasn't translated all possible paths yet. It's initial version number is 0.8, which hopefully represents its release status correctly.