Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use cocoapods for demo project #39

Closed

Conversation

sibljon
Copy link

@sibljon sibljon commented Oct 27, 2013

Essentially, this pull request makes it such that the AFNetworking, DACircularProgress, SVProgressHUD dependencies in the demo project are managed via Cocoapods.

@eduardocallado
Copy link
Collaborator

That’s a good idea and I’ve been thinking of doing it for a while. But actually I don't think very necessary to use Cocapods to manage external libraries on a demo project, and here are some reasons:

  • A demo project is made so the library can be tested in a fast way after downloading it. Having to use the 'pod install’ command to make the project build is kinda boring.
  • One of the main reasons to use Cocapods is to keep the external libraries up-to-date. Although is very good to be updated, on a demo project this is risky, because it may cause some incompatibilities. I know there is the possibility to set a specific tag in the Podfile, but this would be the simliar to use a static library, since it would have to be changed everytime there is an update.

@jpc1957
Copy link

jpc1957 commented Nov 12, 2013

The demo project seems to run fine on ios6.1. If i use CocaPods we are limited to ios7. Is there any reason for the limitation? Can I use IDMPhotoBrowser on ios6.1 also?

@wimaha
Copy link

wimaha commented Nov 13, 2013

I compiled my app using IDMPhotoBrowser with target to iOS 6.0! I think the cocoaPods file could be updated to minimum target iOS 6.0!

@sibljon
Copy link
Author

sibljon commented Dec 6, 2013

A demo project is made so the library can be tested in a fast way after downloading it. Having to use the 'pod install’ command to make the project build is kinda boring.

I see your point, but I would argue that your Pods/ directory should be tracked in your git repo to begin with.

One of the main reasons to use Cocapods is to keep the external libraries up-to-date. Although is very good to be updated, on a demo project this is risky, because it may cause some incompatibilities. I know there is the possibility to set a specific tag in the Podfile, but this would be the simliar to use a static library, since it would have to be changed everytime there is an update.

If you track the Pods/ directory in your git repo, you wouldn't have this problem. If, later, you wanted to add a new pod to the demo project, pod install wouldn't update existing pods.

@eduardocallado
Copy link
Collaborator

After a while, I decided to use Cocoapods on the demo project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants