Author Archives: ssumbera

Mobile processors & iPhone 5S

Rise of mobile processors:
http://www.pcpro.co.uk/features/378712/rise-of-the-mobile-processors/3

iPhone 5S review
http://www.anandtech.com/show/7335/the-iphone-5s-review

iPhone 5S 64bit processor – what does it  mean
http://www.digitaltrends.com/mobile/iphone-5s-64-bit-a7-processor/

Making sense of smartphones processors:
http://www.techautos.com/2010/03/14/smartphone-processor-guide/

Comparing CPU Power Between Smartphones and Notebooks with SunSpider
http://mobilesociety.typepad.com/mobile_life/2012/11/comparing-cpu-power-between-smartphones-and-notebooks-with-sunspider.html

 

Going native: cheaper than you may think

quoted from here:  http://www.intelliware.com/going-native-cheaper-may-think/

 

A commonly held belief is that writing native mobile apps is expensive, especially when you need to support multiple platforms. A related belief is that writing apps using HTML5 or a Mobile Application Development Platform (MADP) tool entirely solves the cost issues associated with cross platform application support

The hard truth is: getting an app to run effectively on multiple mobile OSs using any of these methods is more complex than you may realize. If your goal is to optimize the end-user experience, the cost difference between writing native apps tailored for each mobile OS experience and writing a generic app that runs properly in all mobile environments may be less than you expect.

****

“From a developer’s point of view, one of the greatest advantages to native development is the freedom from worry about cross-platform compatibility. You are able to use hooks and features unique to a specific OS without having to create workarounds for other platforms. Similar features (e.g. share) that are implemented differently across platforms are far easier to develop. The code is cleaner and easier to maintain. Above all, you can get the most out of each platform and present the user with the best experience, all without wasting time “optimizing” code so your app is responsive. Native apps are almost always responsive without effort. The compiler optimizes the native UI widgets for you and the native SDKs force you into sensible design patterns for the mobile platform.

There is a drawback: you are now supporting multiple code bases and all the maintenance that this implies. That’s a pretty big negative, but it does hide an advantage: handling updates. In a multi-platform solution, an update to one OS may bring new conflicts that have to be resolved on the other platforms, which should not have been affected by that update. A native solution should give you less cause for maintenance in the first place, and OS updates should be much easier to apply to your app. The only time you will need to modify all your code bases is when your app is updated. Ideally, you have designed your app such that most of the functionality requiring updates is handled by the back-end.”

Going native: cheaper than you may think

quoted from here:  http://www.intelliware.com/going-native-cheaper-may-think/

 

A commonly held belief is that writing native mobile apps is expensive, especially when you need to support multiple platforms. A related belief is that writing apps using HTML5 or a Mobile Application Development Platform (MADP) tool entirely solves the cost issues associated with cross platform application support

The hard truth is: getting an app to run effectively on multiple mobile OSs using any of these methods is more complex than you may realize. If your goal is to optimize the end-user experience, the cost difference between writing native apps tailored for each mobile OS experience and writing a generic app that runs properly in all mobile environments may be less than you expect.

****

“From a developer’s point of view, one of the greatest advantages to native development is the freedom from worry about cross-platform compatibility. You are able to use hooks and features unique to a specific OS without having to create workarounds for other platforms. Similar features (e.g. share) that are implemented differently across platforms are far easier to develop. The code is cleaner and easier to maintain. Above all, you can get the most out of each platform and present the user with the best experience, all without wasting time “optimizing” code so your app is responsive. Native apps are almost always responsive without effort. The compiler optimizes the native UI widgets for you and the native SDKs force you into sensible design patterns for the mobile platform.

There is a drawback: you are now supporting multiple code bases and all the maintenance that this implies. That’s a pretty big negative, but it does hide an advantage: handling updates. In a multi-platform solution, an update to one OS may bring new conflicts that have to be resolved on the other platforms, which should not have been affected by that update. A native solution should give you less cause for maintenance in the first place, and OS updates should be much easier to apply to your app. The only time you will need to modify all your code bases is when your app is updated. Ideally, you have designed your app such that most of the functionality requiring updates is handled by the back-end.”

Web app first if you go with hybrid apps

If you plan to go with hybrid app model, you rely on HTML/JavaScript technology, whose  home  is  web apps. So if the main reason to go with hybrid model is to be multi-platform with single code base, why not to support web apps too (together with hybrid app) ?
Web apps would have some limitations against hybrid apps,  but would be available truly anywhere.
So it is not one (web app) over other (hybrid app), rather I look on (HTML/JS)  web apps as core (and common, shared) minimum  that can be reused for hybrid apps.
here is also interesting statistics/graphs from recent Business Insider:
jpg

iOS7 notes

iOS7 transition guide (UI): https://developer.apple.com/library/ios/documentation/userexperience/conceptual/TransitionGuide/index.html

iOS7 std link problem:  found linking problem (only) on iOS7 , solution is to add libsstdc++ manually into the build phase – link as described here: http://stackoverflow.com/questions/18959691/ios7-only-stdlibc-linking-issue

Fix UI controller layout for iOS6 and iOS7:

http://www.mobinett.com/2013/08/19/ios7-ui-transition-porting-view-controller-layouts-ios6/

// -- hide status bar on iOS7  - add to controller:
 - (BOOL)prefersStatusBarHidden{
 return YES;
 }

-- not iOS7 related but useful: create cell view either from Nib or manually:
 //-----------------------------------------------------------
 -(CategoryCell*) createCell{
  static NSString *reuseId = @"CategoryCellIdentifier";
  CategoryCell *cell = [self.tableView dequeueReusableCellWithIdentifier:reuseId];
  if (cell == nil){
   cell =  [[UINib nibWithNibName:@"" bundle:nil] instantiateWithOwner:nil options:nil][0];
 //cell = [[CategoryCell alloc] initWithStyle:UITableViewCellStyleSubtitle  reuseIdentifier:reuseId] ;
  }
 return cell;
}

Programming iOS6 by Matt Neuburg

Programming iOS6I am using this fat book (mine is  iOS5 version ) as my best reference for understanding all behind the iOS concept programming. What makes me really happy is that Matt provides in-deep look into every important aspect of iOS programming in a style that is not just ‘tutorial for monkeys’ but rather ‘full understanding’ .  His book preview can be also found here : http://www.apeth.com/iOSBook/ in fact this was my original source of the book existence that lead me to purchase it in paper form. Thanks for the online version too !

samples are here: https://github.com/mattneub/Programming-iOS-Book-Examples

 

I hope there will be iOS7 version too.

 

Notes on native vs. HTML apps

This is like fox and stork story, deep or shallow, Native or Html. ( btw. the picture here is from Czech painter “Josef Lada”). As I am more ‘stork’ than fox, I have collected few resources for other ‘storks’ out there.

My understanding is that mobile platforms are ‘extension of the human senses’ and this trends continues with wearable computing devices, smaller, tighter in resources. Doesn’t matter what software you write, whether enterprise or consumer it is extension of us, our finger touch, eye view, near real time.

Stork links :

http://www.marcozehe.de/2012/12/10/why-do-native-mobile-apps-seem-to-win-all-the-time/

http://www.zdnet.com/heres-why-html-based-apps-dont-work-7000012942/

http://mobiforge.com/developing/blog/why-html5-still-presents-some-problems-mobile

http://boagworld.com/mobile-web/the-problem-with-mobile-frameworks/

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

http://j15r.com/blog/2013/07/05/Box2d_Addendum