CocoaPods trunk is moving to be read-only. Read more on the blog, there are 12 months to go.
| TestsTested | ✓ |
| LangLanguage | Obj-CObjective C |
| License | Apache 2 |
| ReleasedLast Release | Mar 2017 |
Maintained by Will Rust, Percy Hanna, KM Dev.
This workspace contains the source files that build the SDK as a framework (KISSmetricsSDK.framework) and the required public interface (KISSmetricsAPI.h). The source files included here are not intended to be used directly in your app.
For implementation details please see: http://support.kissmetrics.com/article/show/ios-sdk-v2
Setting up a framework project requires several steps and may change from one version of Xcode to the next. Rather than listing all the steps here, please refer to this tutorial: http://blog.db-in.com/universal-framework-for-ios/
Import the API class in your AppDelegate and in any classes where you'll be tracking from:
#import <KISSmetricsSDK/KISSmetricsAPI.h>Manual: (Required if KISSmetricsAPI_options.m is not used)
At the top of the application delegate's didFinishLaunchingWithOptions method, add:
[KISSmetricsAPI sharedAPIWithKey:@"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"];Automatic: (Requires KISSmetricsAPI_options.m)
The customer's settings, including their API key, will live in KISSmetricsAPI_options.m
We can build this file for them based on selections made during new KM Product setup
and deliver it along with KISSmetricsAPI.framework and KISSmetricsAPI.h.
If this file is included, attemps to initialize with sharedAPIWithKey will be ignored.
Even if the provided key is different than the key set in KISSmetricsAPI_options.m.
The SDK will support both ARC/non-ARC and 32bit/64bit projects. One test project is included in this workspace for running application integration tests against the build files directly.
All API files will live in the KISSmetricsAPI dir outside of any project.
Projects will link to the shared KISSmetricsAPI dir.
kma_
uth_
KISSmetricsAPI Scheme > iPhone Simulator and Run
KISSmetricsSDK Scheme > iOS Device and Run
UniversaliOS Scheme > iOS Device and Run
You should find the compiled framework KISSmetricsAPI.framework in this repo's root dir.
In order to support arm64, arm7, arm7s both the KISSmetricsAPI lib target and UniversaliOS aggregate target need to be built targeting iOS7 with Standard architectures (including 64-bit)(armv7, armv7s, arm64). To confirm that the these architectures were included in the final framework build, cd into the built KISSmetricsAPI.framework dir and run:
otool -V -f KISSmetricsSDKInternal logging for our own purposes.
Don't use NSLog, use KMALog which can be toggled by KMALogVerbose for release of our compiled SDK and only applies under DEBUG. (see KMAMacros.c)
We may wish to define a KMAInfoLog which will output logs to our customer devs. This should also have a verbose toggle
that the customer dev can control.
Our SDK should always fail gracefully when not in DEBUG. Use KMAAssert over NSAssert to prevent assertions from our SDK when the customer's app has been built for release.
Only use KMAAssert for crucial warnings to the customer devs. Otherwise use NSLog
or KMAInfoLog (if implemented)
We're using OCMockito to aid in unit and application testing. https://github.com/jonreid/OCMockito
The KISSmetricsSDK_framework_builder includes a set of unit tests but because the
framework builder is not an application, application tests of the framework
are conducted under KISSmetricsSDK_buildFiles_arc_imp.
You should write your application tests in KISSmetricsSDK_buildFiles_arc_imp first rather
than rebuilding the framework between each change to the SDK.
Any category added to our SDK framework must use a unique name and every method within must also use a unique prefix to avoid conflicts with customer dev categories!
KMA as a class or constants prefix.kmac_ for any public category methods.kma_ as normal for any private methods.