Wednesday, November 17, 2010

Non-zippo Lighter Fluid In A Zippo Lighter

Fill up iOS old

These days it released the update of my application break down the paste, the new features include support for some features such as iOS4 local notifications, IAD and "multitasking". Multitasking is in quotes because you can use it only for certain types of applications including: VoIP, navigation, ..., and short task to close the app.
For all other cases the mutitasking is a bit 'different, simply put the application is freezes so it has some memory, but does not perform background tasks.
This is a substantial difference that has consequences in terms of development, but we'll talk about it again.
One of the steps which needed more time was right to make my application compatible with some features iOS4, but maintain backward compatibility with iOS3.


Apple say that in this sense has not made it particularly easy question, its documentation is scarce and not easy to understand for a noob. Fortunately, there are internet and my stubbornness, so I was able to explore some really interesting concepts. From the commercial point of view I would not abandon iOS3, many people still use (I for example on my iPT 1 Jan.) and I would have liked to burn these users, the app also came up iOS3 that figure would have done against my clients if I had sawn the update for them?

There are some things to keep in mind some obvious other subtle, I will tell the system that I used. It will come down in technical robbbbbba for developers.
[MOD_DEV ON];
I created two different patterns that the program should be one and one for iOS3 iOS4. Which one to follow is determined by a Boolean variable ( isOS4 ) and the if that verify the flow in critical areas of software, or where it is necessary to choose an operation rather than a 'other.
If you create two different paths to the first invocation of a method present on only one of two iOS the application will crash. Caution seems trivial but it is not. Recently iPasta device did not work on 3.1 (it crashed without hope) most likely because it drew on methods iOS4 iOS3.

The boolean variable is created based on the analysis of functions related exclusively to iOS4. Some dev to include the OS version using the class ask UIDevice and property systemVersion of the operating system version, in reality this approach recommended by Apple, however, is not entirely correct for several reasons. The first is that some wonder if the string provided by the device is equal to ( ISEQUAL ) to be inserted by the developer, the system in case of an update from the user on an IOS device to 4.0. x affect the application operation. Of course, if I set a string of control to 4.0 and you upgraded to 4.0.1 the two strings are no longer EQUAL


The problem is big because the application will not work properly and will have wait times for new review by Apple just to change a string. One approach would be more correct to ask whether the string returned by UIDevice contains one provided by us, but here's the second reason: if Apple releases the 5.x are still screwed, an application that would work with the capabilities of iOS4 for backward compatibility would be reflected in work with those iOS3 (assuming it is still supported). There are other reasons, these are just a few.
Apple recommends basically 3 methods:

  • query the property multitaskingSupported (which attention is only on iOS4 then you must use it to avoid crashes along with the method below), but I needed a different approach to enable local iAd and notifications that are present on all iOS4 unlike the multitasking that is not on the 3G
  • a query method, the underlying instance method that returns a boolean

- (BOOL) respondsToSelector: (SEL) aSelector

  • query creation of a class, that is what I used myself.

class ADBannerView iOS4 exists only on (is that the banner of IAD), if I try to create an instance of this class on an old iOS would certainly crash the application for this is essential to understand if I can use it. Do not create thrusting through the classic
[[ADBannerView alloc] init];
I exploit the potential of this fantastic programming language that is the Obj C, and then create the class from a string, yes , yes you got it .. by a string. Through the function
NSClassFromString () , if you can not create the class function responds with a nil .
is just a section of my code, as you see the string that the step function is just the class name of the banner that ADBannerView and stores the returned value in a variable of type class (ie the type that identifies the classes in ObjC). If this value is nil, the 'IF out of its scope and the variable isOS4 will remain in the seed that is NO. If the class there is a banner is created.


/ / Check if exists banner banner if exists we are in iOS4
Class bannerClass NSClassFromString = (@ "ADBannerView");

if (bannerClass) {
/ / Create the banner
self.isOS4 = YES;
ADBannerView * banner = [[bannerClass alloc] initWithFrame: CGRectZero]
banner.requiredContentSizeIdentifiers = [NSSet setWithObjects: ADBannerContentSizeIdentifier320x50, ADBannerContentSizeIdentifier480x32, nil ]
banner.delegate = self;
self.bannerView = banner;
[banner release];
[self.view addSubview: self.bannerView]
NSLog (@ "Banner created");

}

addition to this approach is also necessary to change the reference the framework required by a weak, this should be done in the target in the General tab, clear only for those frames that require it, ie UIKit for the functions of local notification and IAD to iAd .., if you do not your application will crash.

Another step is the setting info in the design of the deployment target. See picture. I chose 3.1.3 that the application will work with this version of IOS on.

I hope you have understood and not writing nonsense.
you add a few links that I have been helpful.


ALL CONTENT BELONG TO THE AUTHOR AND ARE RESERVED. Used only after authorization.

0 comments:

Post a Comment