CocoaPods is a dependency management tool for iOS apps. Using it you can easily express the external libraries (like StackMob) your app relies on and install them.
Create a new iOS project in Xcode. Here we've created an app named "MobFind".
$ cd MobFind
$ ls -F
MobFind/ MobFind.xcodeproj/ MobFindTests//
We need to create a Podfile to contain our project's configuration for CocoaPods.
$ touch Podfile
$ open Podfile
Your Podfile defines your app's dependencies on other libraries. Add StackMob to it.
platform :ios
pod 'StackMob', '1.0.0beta.2'
Now you can use CocoaPods to install your dependencies.
$ pod install
Your now have a workspace containing your app's project and a project build by CocoaPods which will build a static library containing all of the dependencies listed in your Podfile.
$ ls -F
MobFind/ MobFind.xcodeproj/ MobFind.xcworkspace/ MobFindTests/ Podfile Podfile.lock Pods/
Open the new workspace and we can start developing using the StackMob library
$ open MobFind.xcworkspace
There are many log statements embedded throughout the iOS SDK to help with debugging. The syntax is DLog(), defined in StackMob.h.
To turn this feature on, do the following:
- If you installed with Cocoapods, go to the build settings tab for the Pods project in your workspace. Instructions coming soon if you imported the Static Library.
- Search for the Preprocessor Macros build setting.
- Add SMDEBUG=1 to Debug.
- Build and run under the Debug configuration to get log statements from the SDK.
- To turn off, change the setting to SMDEBUG=0, or just remove it.
In order to test you must download the full source code: `git clone [email protected]:stackmob/stackmob-ios-sdk.git`.
Kiwi specs run just like OCUnit tests. In Xcode ⌘U
will run all the tests for the currently selected scheme.
describe(@"a public method or feature", ^{
beforeEach(^{
//set up
[[someClass stubAndReturn:aResult] aMethod];
});
context(@"when some precondition exists", ^{
beforeEach(^{
//set the precondition
});
it(@"should have a specific behavior", ^{
//verify the behavior
[[aThing shouldNot] equal:someOtherThing];
});
pending(@"should eventually have another behavior", ^{
//pending specs will not execute and generate warnings
[[[anObject should] receive] aMethodWith:anArgument];
[anObject doStuff];
});
context(@"and another condition exists", ^{
//...
});
});
});
Unit tests do not make network requests against StackMob. The project includes a seperate target of integration tests to verify communication with the StackMob API.
cp integration\ tests/StackMobCredentials.plist.example integration\ tests/StackMobCredentials.plist
open integration\ tests/StackMobCredentials.plist
- Set the public for the StackMob account you want the tests to use.
- Create a schema (using the StackMob web console) called
places
. Add a geopoint field calledlocation
and set all Schema Permissions toOpen
. - Create a schema (using the StackMob web console) called
oauth2test
. Add a string field calledname
and set all Schema Permissions toAllow to any logged in user
. - Test the "integration tests" scheme.
By default, custom code tests are turned off. This is because they require you to have specific custom code methods uploaded for your application. To test custom code, do the following:
- Clone the custom code example repository:
$ git clone [email protected]:stackmob/stackmob-customcode-example.git
. - From the root folder navigate to
/java/src/main/java/com/stackmob/example/
. - Replace the contents of the
/example
folder with the files provided by stackmob-ios-sdk. They can be found by navigating from the root of your local stackmob-ios-sdk folder to/integration tests/CustomCodeFiles
. The files areEntryPointExtender.java
,HelloWorld.java
, andHelloWorldParams.java
. - Naviagate back to the root of your local stackmob-customcode-example folder and execute the command
$ mvn clean package
. - Go to your dashboard on
stackmob.com
and click onManage Custom Code
in the left sidebar. - Upload new code and choose the
.jar
file located, from the root of your local stackmob-customcode-example folder, in/java/target/
. It's the only.jar
file there, and NOT the.one-jar.jar
. You should get feedback from the browser that the methodshello_world
andhello_world_params
have successfully been uploaded - it reports the version and create date. - Once you upload the custom code files you are ready to test. In Xcode, navigate to the file
SMIntegrationTestHelpers.h
in the folderIntegration Tests
. You will see#define TEST_CUSTOM_CODE 0
. Just change that to a1
and when you test the "integration tests" scheme you will run the custom code tests found inSMCusCodeReqIntegrationSpec.m
.
- Fork the repository on github and clone your fork.
- Create a topic branch:
git checkout -b make_sdk_better
. - Write some tests for your change.
- Make the tests pass.
- Commit your changes.
- (Go to #2.)
- Make sure your topic branch is up to date with any changes other developers have added to master while you were working:
git checkout master && git pull && git checkout - && git merge master
(git rebase master
for local branches if you prefer). - Push your topic branch to your fork:
git push origin make_sdk_better
. - Create a pull request on github asking StackMob to merge your topic branch into StackMob's master branch.