Wednesday, October 14, 2015

Swift Optionals Questions (?) and Bangs (!)

I haven’t posted in awhile, but with the Swift 2.0 release, I figured it was time to dip my toe back into the swift waters.  I wanted to share my notes and commentary on optionals.

Optional Types


Optional types provide a way to indicate that a value may be nil as opposed to having a value of some given type.  An optional is represented in swift via a simple template enum:

enum Optional<T> : NilLiteralConvertible {
         case None
         case Some(T)
        ...
}
   
So you can declare and use an optional variable like any other enum:

var temperature : Optional<Float> = .None
if temperature == .None {
          temperature.Some = Optional<Float>(70.6)
}

Given how prevalent and useful optional values are the Swift compiler has built in support for special handling of optionals through the ? and ! operators (syntactic sugar).  In addition, swift features such as literal convertibles enable the Optional type to convert nil to/from Optional.None.  Thus we can write the above as follows:

var temperature : Float? = nil
if temperature == nil {
   temperature = 70.6
}

The swift ? operator is used to specify that the value is an Optional and the compiler will automatically represent or wrap that value in an optional.

The ? operator


The example above is using the ? operator.  The ? operator means the value/type is an Optional.  It’s really just some syntactic sugar to make code more readable.  When used on a variable type declaration, this tells swift to treat/convert the type to an Optional type.  Thus the following are 100% equivalent:

var temperature : Float? = .None 
var temperature : Optional<Float> = .None

In addition, because Optional types support NilLiteralConvertible the .None can be replaced with nil as well:

var temperature : Float? = nil 
var temperature : Optional<Float> = nil

Now let’s get to how we set and access Optional values. 

Wrapping and Unwrapping


Keeping with our same example, you can see where the value 70.6 is automatically wrapped (converted to an optional):
 
temperature = 70.6                  // Auto wrapped
temperature = Optional<Float>(70.6) // Explicitly wrapped

The swift compiler knows when we are assigning into a Optional and will automatically wrap the value into an Optional.  Note: This auto wrapping doesn’t work for other types.  It is special to the Optional type.

The question is how do we get the value back out of an optional?  If you try to just access the value, you will get a compiler error as the types don't match:

    let currentTemperature : Float = temperature  // ERROR, TYPE MISMATCH

We could do it like one does it for any enum by using a switch statement:

       let currentTemperature : Float
    switch( temperature )
    {
    case .None: throw someError
    case .Some(let value): currentTemperature=value
    }

However, this is a rather long winded way of getting access to the value and would destroy code readability if this had to be done every time an Optional’s value was needed.  So Swift has several ways to unwrap an optional value:

  1. The ! operator can be used to specify the value is an optional and thus may be nil, but the optional will be implicitly unwrapped automatically upon access.  With ! if you try to access the value and it’s nil you will get an exception/crash.
  2. The optional binding method uses an if let statement to safely unwrap an optional
  3. The guard statement is another form of optional binding that safely unwraps an optional
  4. The optional chaining method allows safe chaining of operations that return optionals

Implicitly Unwrapping (!)


The ! operator can be used to specify the value is an optional and thus may be nil, but the optional will be implicitly unwrapped automatically upon access.  With ! if you try to access the value and it’s nil you will get an exception/crash.  Because of this, you need to use ! carefully.

Keeping with our same example, you can force temperature to unwrap its operational by using the ! operator.  However, an exception will be thrown if the value is nil:

    let currentTemperature : Float = temperature!     // Exception thrown if nil

You can make this safer by checking against nil before you try and access the value:

if temperature != nil {
   let currentTemperature : Float = temperature!
   print( “\(currentTemperature )” )
}

You can also use a ! operator in the declaration of a variable such as:

    var temperature2 : Float! = 72.3

When used in the variable declaration or function parameter, the variable will be treated as an optional just let the ? operator.  However, it will be automatically unwrapped on access.  So the following will work:

    let currentTemperature : Float = temperature2  // temperature2 auto unwrapped

However, if temperature2 is nil an exception will be thrown so use this carefully.  Swift also has several ways to unwrap optionals safely.

Optional Binding (if let)


To help with unwrapping of optionals in a safe way, swift has a special if let operation that only succeeds when an optional isn’t nil.  So building on our example above, we can use if let to safely unwrap temperature to currentTemperature:

if let currentTemperature = temperature {
   // Only get here if temperature != nil
   // currentTemperature will have a value
   // currentTemperature’s scope is only this block
   print( “\(currentTemperature )” )
}

Extra conditions that have to be met can be added via the where operator:

if let currentTemperature = temperature where currentTemperature < 32.0  {
   // Only get here if temperature != nil
   // currentTemperature will have a value less than 32.0
   // currentTemperature’s scope is only this block
   print( “It’s freezing \(currentTemperature )” )
}

One of the issues with optional binding is you can end up with a fair amount of nesting (pyramid of doom).  Swift 1.2 helped this out a little bit by allowing you to specify multiple optionals:

       if let currentTemperature = temperature,
          let value2 = optional2 where currentTemperature < 32.0  {
   // Only get here if temperature != nil and optional2 != nil
   // currentTemperature will have a value less than 32.0
   // currentTemperature’s scope is only this block
   print( “It’s freezing \(currentTemperature )” )
}

However, since the unwrapped values (currentTemperature, value2), are only accessible within the scope of the if let block it can still force unwanted nesting.  Swift 2.0 introduced guards to help with this problem.

Guards


Swift 2.0 introduced the concept of guard statements.  Guards can be looked at in some ways as the opposite of if let optional binding.  Guard statements execute only if the optional’s value is nil as opposed to if let executing only if the optional isn’t nil.  Guards also allow the assigned unwrapped non-nil value to be used after the guard statement.    

guard let currentTemperature = temperature else {
   print( “Unknown temperature” )
   return   // Must exit calling scope of guard
}

// currentTemperature exists and is non-nil after the guard!
print( “\(currentTemperature )” )

The code executed by the guard when the optional is nil must exit the calling context of the guard statement.  If the guard statement is in a loop then continue or break may be used.  If the guard is in a function then return is typically used.  Basically, execution within the context of the block of code containing the guard isn’t allowed to continue beyond the guard statement when the guarded optional is nil.

Optional Chaining


Optional chaining allows you to place a ? operator after the optional value on which you wish to call a property, method, etc.  This will force an optional result to be returned, and if the unwrapped optional is nil then the chain stops and nil is returned.  For example:

    let optionalValue = anOptional?.aProperty  // somevalue would be an optional
    if let value = optionalValue {
       print( “aProperty = \(value)” )
    }
   
As this is called optional chaining, these can be chained as needed.  For example:

    let optionalValue = optional?.optionalProp1?.nonOptionalProp.optionalProp2

If optional, optionalProp1, or optionalProp2 is nil then nil will be returned as the optionalValue.

Of course these can also be intermixed with the ! operator when you want to force an unwrap.  However, if the implicit unwrapped value is nil an exception/crash will happen.  For example:

    let optionalValue = optional!.optionalProp1?.nonOptionalProp.optionalProp2!

In the above example if optional is nil then as exception/crash will happen.  If optionalProp1 is nil then nil will be returned and optionalProp2 won’t get evaluated. If optionalProp2 isn’t nil but optionalProp2 is nil then it will exception/crash.

If the ? operator isn’t used in the chain then the actual value will be returned as opposed to an optional value.  For example.

    let value = optional!.optionalProp1!.nonOptionalProp.optionalProp2!

In the above example value will be the value of optionalProp2, unless one of the optionals is nil in which case you will get an exception/crash so this is very much unsafe and would be of bad practice!

Quick Summary: Questions (?) and Bang (!)


When you see the ? operator it means the value is an optional and thus may be nil.  When you see ! it also means the value is an optional and thus may be nil, but the optional will be implicitly unwrapped automatically upon access.  With ! if you try to access the value and it’s nil you will get an exception/crash.

Conclusion


I hope you found this helpful and interesting.  If you see anything incorrect or if you have different thoughts please share.

Thanks,
Tod Cunningham

References:



Monday, June 23, 2014

Advanced Swift - Part 2

This is a summary of the topics and notes that I found interesting from watching the Advanced Swift WWDC session 404 by John McCall and Dave Abrahams. I highly recommend you watch the session. It also has some commentary from me which you may or may not agree with. Please feel free to join the conversation. You can find Part 1 here.

I have also attached a swift playground file with the sample code for part 2.


Swift Language Protocols


In swift, you can hook into language features by using special protocols. Swift is very much a protocol based language. Some of the language protocols include:

LogicValue if LogicValue {
Printable "\(printable)
Sequence for x in sequence
IntegerLiteralConvertible 65536
FloatLiteralConvertible 1.0
StringLiteralConvertible "abc"
ArrayLiteralConvertible [ a, b, c ]
DictionaryLiteralConvertible [ a:x, b:y ]
Equatable x == y

Let's look at a simple example of implementing the Printable protocol that allows you to provide a custom description that will be used by println.


Unfortunately when using the playground, the Printable protocol isn't used. I assume this will be fixed at some point.

Subscript Declarations


You can use Swift's subscript declarations to add subscripts and even support for subscript ranges. Here is a useful example adapted from a Stack Overflow post that extends the String class to add subscript access to Strings.


This allows for natural String manipulations, which I think should actually be built into Swift:

var string     = "abcdef"
var firstChar  = string[0]
var subString  = string[0...2] // subString equals "abc"
var subString2 = string[2..4]  // subString2 equals "cd"

While you can have your subscript code perform arbitrary work, care should be used to make them behave in a way that is consistent with what people would expect subscripts to do.

Operator Overloading


Swift also supports operating overloading. I'm not a fan of operating overloading as I think it creates maintainability issues. I would advice to use operating overloading very cautiously.

Operators are defined using global functions so they are available outside the scope of the classes they work with:

We also added a new method to our Thing class which is nameWithArticle so it can provide a basic implementation of using "a" vs "an".

The next feature is one that I was hoping Apple was going to bring to Objective-C and that is Generics.

Generics


Generics is a powerful concept that allows you to reuse code while preserving and leveraging strong typing. In fact, we have already used generics (see the Range parameter under Subscript Declarations). No more using an id, NSObject, or in Swift the Any type unless you need something to be truly typeless such as a collection that can hold multiple types or for dynamic polymorphism.

Here is a simple example that shows a generic function that just prints the given value to the console and then returns that value back out. 



Most compilers treat generics as templates and generate additional code for each type instance of the generic. However, Swift doesn't to do this. It only has one instance of the code for its generics. In addition, the Swift compiler generates more efficient code when it can make optimizations based on the type. 

You can also constrain the type information to force it to conform to a protocol. This allows the compiler to know what operations can be performed by the type.  For example:


The above example uses the Equatable protocol to let the compiler know it can perform the "==" operator. There is a lot more on equatable and generics in the session, and I encourage you to watch it. There is some very cool stuff that Swift can do with its generic system. There is a mind blowing example of a generic "memorize" function that is worth studying.

Wrap Up


Lots of people are starting to learn Swift, including myself, so I hope this was helpful. If you see anything incorrect or if you have different opinions please share your thoughts.

You can download the playground file which will allow you to play with and copy and paste all the code used. Note that you will need XCode 6 to run the example.

Thanks,
Tod Cunningham
Five Lakes Studio, LLC
co-founder

Thursday, June 19, 2014

Advanced Swift - Part 1

This is a summary of the topics and notes that I found interesting from watching the Advanced Swift WWDC session 404 by John McCall and Dave Abrahams.  I highly recommend you watch the session.  It also has some commentary from me which you may or may not agree with.  Please feel free to join the conversation. :)

I have also attached a swift playground file with the sample code.


The Simple Thing Class


The first class the session introduced was the "Thing" class.  It's fairly basic, so I went ahead and completed its implementation. This was also the first time I realized that class initializes don't use the "func" keyword!  This is because initializers have some special characteristics that distinguish them from functions some of which is explored later on.


The location can be nil (no object) so it uses the "?" modifier.  We can easily create an instance of "Thing" using named parameters:


The simple Thing class is actually using a simplified version of argument names that make the caller's argument name equal to the name used by the initializer.  You can also create a version that uses the full argument names.

Full Argument Names


You can actually use the argument definitions full form to define argument names that allow the caller of the initializer to use a different name then what the initializer itself uses.


You can also do a condensed version of the arguments where the caller doesn't need to specify the argument name.  This is done through an anonymous wildcard expression.  Let's first take a look at these expressions to see how they work and then we will apply them to argument definitions.

Anonymous Wildcard Expressions (_)


Swift has the concept of an anonymous wildcard expression which is represented by an underscore (_). The wildcard expression can be used when you want to explicitly ignore a value during assignment. This comes in really handy when dealing with tuples.


You can apply the same technique to argument names.

Anonymous Argument Names


Instead of having explicit argument names you can specify anonymous argument names.  This should only be done in situations where the code becomes more readable/maintainable without the named parameters.


To me this is an example where Swift is giving too much flexibility in its expressiveness and is asking for abuse.

Protocols


Protocols are like Objective-C protocols in that they don't provide an implementation.   Here is an example:


This example also introduced the difference between the === and the == operator.  The === means the objects must be the same instance where == just means they need to be equal but not necessarily the same instance.

Testing for Protocol Conformance


You can use a conditional cast to check if an object conforms to the protocol.  However, the example given in the session was incorrect.  When trying to compile it, I kept getting an error "cannot downcast from 'Thing' to non-@objc protocol type 'Pullable'".  According to the documentation under "Checking for Protocol Conformance” you can only test for protocol conformance of objective-c compatible protocols.   This makes the protocol only usable for class types which is fine in this case.  So making the adjustments to the protocol we can now implement a function that tests for conformance.


The example given also only specified the use of the "as" operator as opposed to "as?".  However, the documentation states that "as" will trigger a runtime error if it can't cast to the specified type so we need to use the "as?" operator to allow for cases when the object doesn't conform to the protocol.  So we had to use the "as?" operator as shown above.

Wrap Up


Lots of people are starting to learn Swift, including myself, so I hope this was helpful.  If you see anything incorrect or if you have different opinions please share your thoughts.

You can download the playground file which will allow you to play with and copy and paste all the code used.  Note that you will need XCode 6 to run the example.

Thanks,
Tod Cunningham
Five Lakes Studio, LLC
co-founder

Monday, July 1, 2013

Newsletter

We have had more then 700,000 downloads of our apps since 2010, and we don't have any way to contact those people or know who they are outside of our apps.  For in-app engagement I highly recommend the Apps Fire Booster SDK which I did a blog post about awhile ago.  However, I think we need to be doing more to stay in touch with our users.  I talked with Jody Burgess who runs a strategic marketing company and she planted a bug in my ear about collecting e-mail addresses.

Newsletter Signup


I decided that collecting e-mail addresses would be a good idea, but I wanted to make sure we are adding value for that e-mail address and that we don't spam our users.  Ken and I decided to add a newsletter signup to Picross HD.

We added a simple signup process that will prompt users to signup for the Newsletter.  The signup offer will be shown after several launches of the App or upon request.


We are using a double opt in process that requires the user to ask to signup for the newsletter as shown above and via a confirmation e-mail.

Mailchimp


We are using mailchimp.com to manage the e-mail lists for us.  This helps us stay in compliance with different e-mail laws and manages all the opt-in and out stuff.  They also have a simple little api called ChimpKit on git hub.  I wish they had done a bit more work on it as it's just a very thin wrapper around their rest api, but it is still useful.

They also support localized e-mails, but I have had a hard time getting that setup correctly.  For this first pass, I'm just going to go in english, but I would like to support japanese better in the future as about half the Picross HD user base is japanese.

At the time of this writing, we haven't gone live with Mailchimp so I don't know how well they are going to perform until we get a few e-mail campaigns under our belt.

Privacy Policy


The one thing mailchimp doesn't really help with is in the creation of a Privacy Policy.  If you are collecting names and e-mail addresses you will need a privacy policy.  It cost about $650 to have one created along with a Terms of Use for our website and an End User License Agreement.

Free Puzzles


The main use of the newsletter will be to feature new free puzzles that can be played either via paper or via our games.  Here is an example of what the newsletter will look like:


We keep the e-mail really simple so that it has the best chance of being opened by various e-mail readers, but when you click on one of the puzzles it will open the puzzle in our puzzle view.

Puzzle Viewer


The puzzle view is interesting because it uses Javascript to give the user more options.  For example, if you have it open on an iOS device it will give you the option of installing Picross HD or if you have Picross HD already installed it will give you the option to play the puzzle directly in Picross HD.

If you are viewing it on a computer it gives you the option of download Picross HD through iTunes or print the puzzle.  You can even show the puzzle's solution so it's possible to play the puzzle with pen and paper.  We hope users will play it in Picross HD, but we want people to share our puzzles with their friends and have no barriers to playing our puzzles.


It was a little tricky to get it to work, just contact me if you would like me to share the Javascript code with you or you can view the page source to see it yourself.

The nice thing about the Puzzle view is we will also be able to do some social campaigns on Facebook and Twitter.  I plan on posting free puzzles to Facebook and Twitter which will bring people to the Puzzle viewer.  They will hopefully enjoy the puzzle and choose to signup for the newsletter or download Picross HD.

Cross Promote


In addition to Picross puzzles, we plan on making Hashi puzzles available through the newsletter.  We think people who like Picross puzzles will also probably like Hashi puzzles and this is a way to introduce them to Hashi puzzles and our Hashi app.

We will also use the newsletter to talk about upcoming releases and news we think our users may be interested in hearing about.

Conclusion


It's kind of amazing all the possibilities that open up just by having interested user's e-mails.  I'm excited to see how this goes over with our users and through our planned social campaigns.

Please feel free to follow me on twitter at @fivelakesstudio. I would love to hear about your app marketing experiences.  Also, feel free to signup now for our newsletter.  It may still be in a beta form, and it won't be able to open puzzles in Picross HD until the 3.4 version is available.  Other then that it should work fine.  :)


Thanks for reading and be sure to visit us at Five Lakes Studio.



Monday, April 8, 2013

iOS In-App Purchases

This is hopefully a concise getting started with in-app purchases article. Five Lakes Studio has had a fair amount of success with leveraging in-app purchases, and I wanted to share some of the lessons we have learned along the way and also share some code to help make basic in-app purchases a little easier.  This article focuses on non-consumable purchases with built-in product (app) delivery.

Setting Up Your Account


In order to use in-app purchases you have to complete several steps.  A good guide to how to do this is  TN2259 Adding In-App Purchase to your iOS and Mac Applications.   I would recommend taking some time and reading it thoroughly.

One of the key things you need to do is make sure your app has a specific AppId such com.appleseedinc.MyGreatApp.   If your current AppId is using wildcards (".*") you will need to replace it with a fixed AppId and regenerate and reapply the provisioning profiles.  This is because in-app purchases can't be shared across multiple apps.

Creating Test Accounts


You will also need a test account.  These can be created using your iTunes Connect account.




In order to test with the test account, you will need to logout of your current iTunes AppStore account.  You can do that in the "Settings" app under "iTunes & App Stores".


However, don't try to login with the test account through the Settings app.  The test account is only valid in the sandbox environment.  In order to use it, you enter it from within you app when you initiate the in-app purchase.  It will then ask you to login and then you can use the test account you just created.  Once you do this, you can logout of the test account through the Settings app.

Setting up In-App Purchases


You setup the items you want to be purchasable via iTunesConnect.  


This includes picking the type of in-app purchase, it's product id used to reference the purchase from within you app, pricing, and finally the actual text displayed to the user during the purchase process.

This article focuses on Non-consumable In-App Purchases.  These type of purchases only need to be purchased once by users. They do not expire or decrease with use and they can be restored.

Purchasable items need to be approved by apple, and they must include a screenshot.  When you define a new release of an app you can pick which new in-app purchases are available in the app.

It's App Time


Now it's time to start doing work in the app.  At this point, you should have your AppId provision profile set, a test account setup, and one or more non-consumable purchases configured in the App Store through iTunesConnect.  The StoreKit is used to communicate between your app and the AppStore.


The simplest type of in-app workflow to implement is for built in product delivery.  The workflow looks like:


The other workflow is a server based authentication workflow which is significantly more complicated and isn't a focus for this article.

I have made available a class called FLOStoreManager that helps manage the built in product deliver workflow and is part of the Five Lakes Studio Open Library project on GitHub.

FLSOpenLibrary


I'm happy to make FLOStoreManager available under the MIT license as part of the Five Lakes Studio Open Library on GitHub.  The FLOStoreManager class does most of the work to manage the in-app purchase process.   I suggest you download it and at least use it as an example.  

NOTE: The FLOStoreManager makes reference to featureId which is equivalent to to the App Store productIdentifier.

There are 3 main parts to the in product delivery process: Download, Present, and Purchase.

Downloading Purchasing Information


The in-app product definitions are stored on the App Store and must be download to the app before presenting or trying to purchase the item.  This is a download of the product information or meta-data such as product price.   Apple enforces this through the App review process so don't try to skip this step even if you think you can just embed all the meta-data in the app.  Apple still requires your to download and honor this information as it exists in iTunesConnect.

The product definitions contain information such as product description and price. In order to fetch the product definitions, the app needs to know the product ids in advance.  There is no method to query the product ids from the App Store.  This means the App needs to know the product ids by either hard coding them or by other means such as downloading them from a server.

The SKProductsRequest class is used to fetch the product definitions for a set of feature id's.  The FLOStoreManager wraps this in a handy method called startAsyncFetchOfProductForFeatureList.

- (void)applicationDidBecomeActive:(UIApplication *)application
{
    NSSet *featureSet  = [[NSSet alloc] initWithArray:@[@"ProductId1", @"ProductId2"]];
    [[FLOStoreManager defaultManager] startAsyncFetchOfProductForFeatureList:featureSet];
}

This implementation also does some handy work for you automatically:
  • Auto retry on failed attempts
  • Sends an NSNotification (kFeatureListReady) when the feature list has been successfully retrieved.
  • If the feature list has already been retrieved and matches the given feature then it will only try and update the list once a day.   This is handy since it is called in applicationDidBecomeActive which may get called multiple times as users enter and leave the app.
  • Keeps track of the "registered" features and the product information associated with them
I usually request the product information during applicationDidBecomeActive so it will be downloaded and available as soon as is possible so the purchasable items can be presented to users.

    Present Purchasable Items


    It's up to you to decide how to present the in-app purchases to your users.  However, the App Store uses UIAlert messages which you can not control other then through some text customization.  These customizations are done through iTunesConnect when defining the in-app purchase.

    Picross HD - Daily Puzzle Pack In-App Purchase
    You also shouldn't present purchases for items whose purchasing information hasn't been downloaded.  Apple can reject your app if you try to do that.

    One of the things you are going to want to know from the server is the price of the item.  This can vary based on the country and also can be changed in iTunesConnect.  FLOStoreManager has a handy routine to allow you to retrieve the localized price of the product formatted in a nice string.

    NSString *price = [[FLOStoreManager defaultManager] formattedPriceForFeatureId:@"ProductId1"];
    

    You will also want to take into account some other factors in the UI such as:
    • The act of purchasing an item is done asynchronously so you will probably want something to indicate when a purchasing is in progress,
    • You will need to handle the notifications when the purchase either completed or failed. 

    Purchase


    The SKPaymentQueue is used to initiate a purchase.   It's easy to initiate a purchase, but it does require some tricky handling of the payment queue.  FLOStoreManager tries to make this really easy.  You just call startAsyncPurchaseOfFeature to begin the purchase:

    [[FLOStoreManager defaultManager] startAsyncPurchaseOfFeature:@"ProductId1"];
    

    Once the request is completed, one of two NSNotifications will be sent:
    • kFeaturePurchased is sent if the purchase is successful. The notification object with be the featureId NSString
    • kFeaturePurchasedFailed is sent if the purchase failed.  The notification object with be the featureId NSString
    FLOStoreManager also keeps track of which product ids (features) are in the process of being purchased.  This is handy when updating or displaying a view and you need to know if something is being purchased.


    if( [[FLOStoreManager defaultManager] isFeatureBeingPurchased:@"ProductId1"] )
    {
        // The feature is in the process of being purchased
    }
    
    if( [[FLOStoreManager defaultManager] isAnyFeatureBeingPurchased] )
    {
        // Some feature is being purchased, we don't care which one
    }
    

    One of the limitations with FLOStoreManager is that it doesn't try to do purchase receipt validation. There is a vulnerability in iOS 5.1 and earlier related to in-app receipt validation.   It is not a simple topic to validate a receipt.  Apple has a handy article that talks through the "In-App Purchase Receipt Validation on iOS".  If people are willing to go through the hassle to hack my app to save a buck or two then so be it, I don't think they would be willing to pay for it anyway.  Perhaps some day they will change there ways.

    You will also need to handle the condition of a purchase request that gets completed after the user has left your app.  In order to handle this case, one of the first things the app should do is setup the  SKPaymentQueue in application:didFinishLaunchingWithOptions by adding an observer.  This needs to be done so the app can receive payment notifications from the AppStore.  This is all taken care of by FLOStoreManager just by getting the defaultManager.

    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
    {
        [FLOStoreManager defaultManager];  // Allows us to receive AppStore notification
    }
    

    Once the user starts purchasing items, how do you track what has been purchased?

    Purchase Tracking


    It is up to the app to figure out how to store and keep track of purchased items.  The StoreKit does provide a method called restoreCompletedTransactions which is available as part of SKPaymentQueue  to restore non-consumable purchases.  However, it requires that the user provide their authentication to the Apple Store.  So it's usually called in response to an explicit action by the user to restore purchases.

    FLOStoreManager exposes the ability to restore purchases through its own restoreCompletedTransactions method.  Using  FLOStoreManager also has the added benefit of sending kFeaturePurchased notifications for items that where purchased and needed to be restored.  It will also send a kPurchaseRestoredCompleted notification after all items have been restored.

    The other big advantage of FLOStoreManager is it has a built in mechanism to keep track of non-consumable purchases.  It uses the built-in keychain to keep track of purchases.  The nice thing about the keychain is that it persists across deletes of the app.  You can also instantly query FLOStoreManager to see what has been purchased.

    if( [[FLOStoreManager defaultManager] isPurchased:@"ProductId1"] )
    {
        // The feature has been purchased
    }
    

    Conclusion


    Wow you made it this far.  This turned out to be a wee bit longer then expected, but I hope you found it useful.

    Please feel free to contribute to the FLS Open Library.  I wasn't planning on making this open source so it wasn't designed to be general use, but I think it provides a good start and example.  It also contains a lot more functionality then discussed here including an extension to handle consumable purchases.

    Please feel free to follow me on twitter at @fivelakesstudio. I would love to hear about your in-app purchase experiences.

    Thanks for reading and be sure to visit us at Five Lakes Studio.

    References


    https://github.com/FiveLakesStudio/FLSOpenLibraryIOS.git
    TN2259 Adding In-App Purchase to your iOS and Mac Applications
    In-App Purchase Programming Guide
    In-App Purchase Receipt Validation on iOS
    iPhone Tutorial – In-App Purchases By Mugunth Kumar


    Sunday, April 7, 2013

    Quick Tip: How to show source code in the blog

    I have been trying different solutions for showing source code in my blog.  This has been a little harder by the fact I'm trying to show Objective-C.  I have finally found just the trick. It's http://hilite.me/ by Alexander Kojevnikov.  It has a very simple copy/paste interface that just works.  You can also do some customizations and pick between may different styles.

    Using it is as simple as:
    1. Paste your source code
    2. Hit Highlight
    3. Copy and paste the HTML


    You can also customize the embedded css style information and pick the language.  I added a font size style to the css "font-size:small;" and here is what it looks like:

    - (void)alertViewCancel:(UIAlertView *)alertView
    {
        if( m_alertBlock != nil )
        {        
            m_alertBlock( kAlertViewCanceled );
            m_alertBlock = nil;        
        }    
    }
    

    The nice thing about this solution is that everything needed is embedded in the HTML block so there is no setup required on the blog itself.

    Please feel free to follow me on twitter at @fivelakesstudio. I would love to hear if this was useful and what you do to show source code on the web.

    Thanks for reading and be sure to visit us at Five Lakes Studio.

    Wednesday, March 13, 2013

    Cocoa Debugging Tip


    I'm attending my local Ann Arbor CocoaHeads meeting tomorrow, and the topic is
    Objective Tips.  So I thought I would share a tip.

    What do you do when you get a crash due to an uncaught exception such as:

    2013-03-13 13:30:10.186 Picross[43233:1303] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[AppDelegate crash]: unrecognized selector sent to instance 0xc04de10'*** First throw call stack:
    (0x355b012 0x32ffe7e 0x35e64bd 0x354abbc 0x354a94e 0x3313663 0x12f54 0x3f0153f 0x3f13014 0x3f042e8 0x3f04450 0x926b5e12 0x9269dcca)
    libc++abi.dylib: terminate called throwing an exception

    This can get really frustrating as you need to figure out where in your code it crashed.  Debugger to the rescue.  In the call stack, you can find the first "low" value.  This usually represents your code.  Then you just do a symbol lookup on that value.  Such as the following when using LLDB.
    im loo -a 0x12f54
     This does a image lookup which gives a nice dump including the file and line number of the offending code:

    Address: Picross[0x00012f54] (Picross.__TEXT.__text + 67540)
    Summary: Picross`__57-[AppDelegate application:didFinishLaunchingWithOptions:]_block_invoke112 + 52 at AppDelegate.m:216

    You can see from this dump that the offending code was at line 216 in the AppDelegate.m and was from a block where I was calling a selector that didn't exist.


    I also find this GDB to LLDB guide to be a handy reference of the commands available in LLDB.

    I hope this short quick tip was helpful.  Please feel free to follow me on twitter at @fivelakesstudio. I would love to hear about your experiences with the debugger or any tips you might have.