하이브리드앱에 대한 개발자와 기업의 자세

재미난 개발관련 트윗을 하시는 김홍준(@jun0683)님의 트윗으로 부터 가져온 블로그 포스트입니다.
순수 기술 기반 회사에서 일하다가, 개발 팀 구성도 제대로 안되어 있고, 소프트웨어 개발에 대한 이해가 부족한 회사로 몇년전에 옮겨 왔는데, 그러다 보니 개발 환경에 대한 이해 자체를 개발 시안을 내는 사람이 잘 못하고 있어서 중구 난방의 계획을 세우고 그러다 보니 뭐 하나 제대로 안되는 경우가 있습니다. 그러다보니 웹 앱 개발이냐 네이티브 개발이냐, 안드로이드 개발이냐 iOS개발이냐 너무 왔다 갔다 하다 보니, 이런 저런 생각을 하게 되는데, 제가 생각한 것도 있고, 미국인들이 쓰는 블로그도 있는데, 한국분이 괜찮은 포스팅을 했구나 싶어 여기에 소개 합니다.

http://rintiantta.blog.me/40184656765

Well choreographed web site for mobile web developers

I happened to read some articles here at mobiForge.
It’s for mobile web app developers and articles are organized really well.

For example, “Starting”, “Designing”, “Developing”, “Testing” and “Running” are the main titles.
So, you can easily find articles for those each step.

difference in auto synthesis and “traditional” synthesis

After the introduction of iPhone SDK, many things have been changed very quickly.
Some were changed very publicly, while some didn’t. Even though there is no explanation on those changes, you could figure out some by taking a look at basic template code which Xcode puts by default.
However, some are hidden.
I was away from iOS/Mac development for a while and tried to catch up stuff recently. One of the simple but astonishing one was the internal member variable Objective-C preprocessor creates.

For example, let’s say that interface file looks like this.

@interface JAWindowController : NSObject

@property (retain, nonatomic) IBOutlet UIToolbar *toolBar;
@property (retain, nonatomic) IBOutlet UIButton *buttonOne;
@property (retain, nonatomic) IBOutlet UITextView *textViewOne;

@end

Then when ARC is off and auto synthesis is used, it creates those internal variables which matches their properties with “_” prefixed to the property name.

#import "JAWindowController.h"

@implementation JAWindowController

- (void)dealloc
{
	[_buttonOne release];
	[_textViewOne release];
	[_toolBar release];
	[super dealloc];
}
@end

However, if explicit synthesis is used, it will create the default internal variable names same to their property names like this.

the red underlines means a variable with such a name doesn’t exists.

When ARC is on, it’s the same like the case of ARC is off. The only difference is that it doesn’t create dealloc message for you automatically, because usually it’s not necessary because Objective-C objects are to be released automatically by ARC mechanism.

Is Google intentionally introducing “fragmentation” to Android market?

This is very interesting article.
Android fragmentation predicted to squeeze out independent developers

Well, I’m currently working on an iOS program, which was originally implemented by some people in an outsource company. One major problem is that they didn’t understand the philosophy of Cocoa framework and Objecitve-C. So, there are maany wrongly written piece of code as well as wrong memory management, wrong view management, etc.
So, to fix some problems asked is very irritating because I have to fix those things hidden to end users as well as visible problems to people here at….

Then, unnecessary “fragmentation” occurs even on this beautiful and clean iOS platform. Often, I have to work around the wrongly written code, because people in my company didn’t understand why it coudl take longer time than they expect, because to them, the “surface” problems look small. For better management of projects, I fix fundamental problems in architecture, coding etc if that is to give me hard time. ( to work around studid code is not feasable sometimes. ) Anyway, because I have to find a way to work around some problems which are better not to solve at this moment, there must be some code which can be odd.

Then, if a platform has its inheretant fragmentation, how much headache it can give?

So, I don’t expect Android developers test their projects on every Android platform. They would choose only the major devices they think. The “circle” of the major devices can be different among people. So, Google found out that they needed “reference devices”, but they don’t look to be consistent for themselves.

So.. yes.. I expected this kind of news, which says that fragmentation expel indepedent developers. Actually it’s not only those small developers who are affected by the problem. In companies, where they have S/W dept. managers who don’t understand S/W development, would raise question to his/her S/W engineers request to buy more Android devices to test for. Then, the frustrated developers would just give up testing on more major devices, they would say, “Ok. Nowadays Sammy Galaxy 3 is hot. So, it’s OK if my program runs on it Ok.”. This will cause them to miss non-negligiby large target audiences.

On the other hand, I started to think that Google people may enjoy this fragmentation issue. You know, Google invests heavily on HTML5/AJAX. They can be the next MS once everything is to be written with HTML5/JavaScript and computers are like Chrome books. Well… I’m also threatened that I have to update my knowledge on HTML5 especially on AJAX. ( Although it was interesting, I stopped writing code in HTML5/JavaScript long time ago. ) Compared to C/C++, it’s fairly easy, and more over I already know them. So, updating with the lastest idioms and techniques wil be easy. However, I have to expand my major interest over too many things.
In 90’s it was easy to keep up to date on Perl, CGI, PHP, JavaScript, HTML, Win32/MFC, Mac, Unix, C/C++, SQL etc. But nowadays it is pretty hard.

However, thanks to the success of iPhone, native programming is still strong.
Then Google people may think that HTML5/JavaScript based computing is a strong environmeent to go over traditionally strong players in this industry.

Yeah… probably, Goole wants people to be frustrated by the fragmentation of Android. Many people will think that even iOS has that fragmentation and would not try at all.
Also, business oriented people tend to prefer write-once & deploy-on-all approach. It was things like Java, Mono .NET, etc. But while HTML/JavaScript started to have the flexibility of native languages, those folks started to prefer them over native dev., because they don’t need to maintain C# programmers, C/C++ programmers, etc.

It makes sens from one point of view, but not at all from different angle.
I hate it.

Getting camera resolution on iOS devices

Apple doesn’t provide easy to use class or messages to retrieve camera resolution. However, people are saying that there is a way to get the information.

So, based on that, I wrote this code.

- (void) setupVideoCaptureSession
{
	self.isSetUpOK = true;
	
	self.cameraCaptureSession = [[AVCaptureSession alloc] init];
	
	self.cameraCaptureDevice = [AVCaptureDevice defaultDeviceWithMediaType:AVMediaTypeVideo];
	bool isBackCamera = ([self.cameraCaptureDevice position] == AVCaptureDevicePositionBack);
	
	NSError *error;
//	NSLog( @"position : %@", ([defaultCaptureDevice position] == AVCaptureDevicePositionBack)? @"Back":@"Front" );
	if (isBackCamera)
	{
		self.cameraCaptureDeviceInput = [AVCaptureDeviceInput deviceInputWithDevice:self.cameraCaptureDevice error:&error];

		if( error == nil )
		{
			// Start of bulk configruation :It's not really needed here, but just in case...
			[self.cameraCaptureSession beginConfiguration];
			
			if( [self.cameraCaptureSession canSetSessionPreset:AVCaptureSessionPresetPhoto] )
				self.cameraCaptureSession.sessionPreset = AVCaptureSessionPresetPhoto;
			
			// End of bulk configuration
			[self.cameraCaptureSession commitConfiguration];
			
			
			[self.cameraCaptureSession startRunning];
		}
		else
			self.isSetUpOK = false;
		
	}
	else
	{
		self.cameraCaptureDevice = nil;
		
		self.isSetUpOK = false;
	}
}

- (CMVideoDimensions) cameraResolutionDimension
{
	CMVideoDimensions resolutionDimension = { 0, 0 };
	
	if( self.isSetUpOK )
	{
		if( self.cameraCaptureSession.isRunning )
			NSLog( @"capture session is running.");
		else
			NSLog( @"capture session is not running");
		
		
		for( AVCaptureInputPort *port in self.cameraCaptureDeviceInput.ports )
		{
			if( [port mediaType] == AVMediaTypeVideo )
			{
				self.cameraCaptureInputPort = port;
				CMVideoFormatDescriptionRef descRef = [port formatDescription];
//				resolutionDimension = CMVideoFormatDescriptionGetDimensions([port formatDescription]);
				resolutionDimension = CMVideoFormatDescriptionGetDimensions(descRef);
			}
		}
	}
	
	return resolutionDimension;
}

If setupVideoCaptureSession and cameraResolutionDimension are called in that order, it should retrieve the camera resolution dimension in pixels. However, it doesn’t. A guy told me that it’s a bug. So, I filed it.

But I’m not sure. This is so apparent. How come Apple guys pass this stuff through their SQA process? As a person who have know their quality, it should not happen. Nowadays I notice lots of bugs in their tools, frameworks, etc. What’s happening in Apple nowadays?

Great tip to figure out view hierarchy

According to objcguy, you can figure out view hierarchy with one call.

http://msxfan.com/nsview-subtreedescription

Good starting point for people who are interesting in how to populate file system in a very low level?

This tutorial uses FatFS as a library to initialize FAT file system on an SD memory and create/open/read/write/close/delete files using the FatFS.

Which one to use? NSTimer or timer dispatch_source?

Well, as I said in my previous post, Apple people don’t maintain AppKit framework as they did before.

So, as a developer you would need to decide functions from which framework to use. What I means is, for example when Apple introduced a feature in Core Graphics, a corresponding NS* class and its messages used the newly implemented feature in Core Graphics. So, you don’t really need to access Core Graphics directly except for some special cases where you need to access those lower level functions than AppKit directly.

However, now you will decide which one to use more frequently than you did so before.
For example, scheduledTimerWithTimeInterval:invocation:repeats of NSTimer doesn’t look to use the timer dispatch_source. if it uses timer dispatch_source internally, you will not need to worry about which one to use. But now you should do so.

There can be some reason you would prefer using NSTimer message.

1. You have old source code which was written for OS X earlier than OS X 10.6 Snow Leopard and want to keep the source code
2. You want to ensure source code level compatibility with older OS X. ( Well, you would say the version of Xcode required to build for the older OS is not installable on current Mac OS X. But if your company is serious about supporting older but still decent OS X, they should keep the dev. environment for you.
3. You want to ensure source code level compatibility with GNUStep. ( I wonder how many people/companies actually care about GNUStep for commercial S/W. )
4. You prefer the simple NSTimer use pattern.

However, you would prefer using the timer dispatch_source if you want :

1. Better performance  and caring of multi-core architecture environment more well presumably
   • NSTimer is scheduled in Run-Loop, while dispatch_source is in GCD space. So, inherently dispatch_source will utilize multicore architecture more well, although it could be negligible practically.
2. higher timer resolution ( NSTimer is in seconds, while dispatch_source is in nanosecond )
   • Probably this is the strongest reason you want to use dispatch_source.

Any other reason to prefer one to the other?

How Apple people have implemented features in Cocoa framework

Yes. the way Apple migrate newly implemented feature between Mac OS X and iOS is different now.

Originally, if implementing on Cocoa framework was like this :

1. popular messages used in AppKit/Foundation are implemented on Core * level including Core Foundation. So, people who cares performance can directly call Core Video, Core Text, etc and Core Foundation functions. AppKit and higher object oriented approach was implemented using the newly implemented C based Core * functions.
2. When new features are implemented with certain performance target, they were implemented on Core * level and for immediately imaginable popular features they implemented AppKit level of interface(class) on top of the Core * functions. Then in following update of the OS or version of the OS, they introduce more features introduced in Core * level to its corresponding Obj-C class

However, nowadays, the pattern looks to be broken.
One of the examples is  the timer source in the GCD space. Some of the dispatch source behavior can be also implemented on NSFileHandle class and any other interfaces starting with NS, i.e. in AppKit. However, it doesn’t look to me that they don’t so far. GCD was introduced in Snow Leopard ( if my memory is still good. ) Then, although it would not be possible to introduce corresponding features in AppKit, by now they should have done. 

It looks to me that they are just busy in migrating new features introduced in iOS to Mac OS X in Core * or other  underlying frameworks only.

Although it may not confuse new iOS developers since the introduction of iOS, to us, who are long time developers on Mac OS X, it feels a little odd and feels like things are not being done as completely as Apple people did it a while ago.

If Apple is not going to give up OS X and still do care of sound framework design, they should hire more developers in framework team and should invest their time to train the new developers to speed up framework development at Apple, I think.

To simulate iPhone camera on your iOS simulator…

Although I didn’t test it yet ( I’ll do shortly ), this project looks very interesting.
I know iOS 5 simulator is not worth while to trying at all. Screen rotation, applying CGAffineTransform etc blah blah don’t work on iOS 5 simulator as it does on a real device. Sometimes the buggy iOS 5 simulator works more correctly for certain features than real iOS 5 devices.

Now even with iOS 6, it can be handy to test your code with a simulator without hooking up your iPhone.

So, let’s try this to see how far it can go!
UIImagePickerController-SimulatedCamera from the holly GitHub!

NOTE : Currently it doesn’t work.