Friday, August 31, 2012
NSMutableArray Weak References
I had the need to store non-retained objects to prevent a retain lock loop. I found a couple of different ways to do this. I started by trying to implement a derived version of NSMutableArray. There is a nice example by Mike Ash on how to do implement a NSMutableArray. It would be fairly easy to modify his example to remove the retain/release pieces. However, I was a bit nervous when it came to testing the code and my changes. While he has a test in place, the test wouldn't work if the objects weren't retained.
So I kept looking and found a great example on Stack Overflow by Mark Powell that takes advantage of Core Foundation's Mutable array.
I haven't done much with Core Foundation services, but I have to say that it's amazing how easy this was to do. I modified the example above to work with ARC so there is a __bridge cast for the returned CGArrayCreateMutable. I put this along with my changes in a small class and header file which can be downloaded at Download NSArrayWeakReference Source.
I hope you found this helpful.
- Tod
Monday, August 27, 2012
Japanese App Store Withholding
I learned an interesting lesson this weekend. I was reviewing our AppStore financial results and I noticed an interesting entry:
After a little bit of research, I learned Apple withholds a 20% tax on Japanese sales. In order to eliminate this tax, you need to file some tax forms with the Japanese government and US government. Apple helps with this process by providing and submitting the forms.
David Smith has a nice article on "Understanding Japanese App Store Withholding" that goes into more detail.
I filled out the forms this weekend (8/26/2012), and I will report back on when it takes effect. I would love to hear about year experiences with this process.
After a little bit of research, I learned Apple withholds a 20% tax on Japanese sales. In order to eliminate this tax, you need to file some tax forms with the Japanese government and US government. Apple helps with this process by providing and submitting the forms.
David Smith has a nice article on "Understanding Japanese App Store Withholding" that goes into more detail.
I filled out the forms this weekend (8/26/2012), and I will report back on when it takes effect. I would love to hear about year experiences with this process.
Monday, August 13, 2012
Subversion to Git
A couple weeks ago Ken and I decided to make the plunge from Subversion to Git. The main catalyst for this was some Hype generated files I wanted to check into Subversion. Unfortunately, every time you generate the HTML for a Hype project it blows away the folder structure, which removes the .svn folder and gets subversion all confused. I understand there are newer versions of Subversion that resolve that issue, but I decided to just do the switchover to Git given that's where it seems most people are going today.
Given Ken and I work together on projects we need a version control hosting provider. We currently use Beanstalk for subversion, and we have been very pleased with them. However, I decided to take a look at the available options. I took a serious look at GitHub and Bitbucket. I opted to go with GibHub for our main git repository. I really liked its interface and how it links your personal account to your corporate account. Plus it has a big user following. Several reviews I read also talked about GitHub being more performant and a step ahead of Bitbucket. However, that info could be a bit dated by now.
We opted for GitHub's $25 per month plan for 10 private repositories. However, I also created a Bitbucket account as they have free unlimited private repositories. I'm using bitbucket to host paid for 3rd party assets, and I'm using GitHub for our source.
While lots of people use the command line to manage Git, I prefer having some nice GUI tools for my day to day work. There are several tools out there, but I ended up going with SourceTree. It seems to be the most complete tool for managing subversion repositories. I also used GitHub's tool for awhile to get up and started, but SourceTree feels like a more complete and powerful solution.
I decided not to do a full history migration from Subversion to Git. I opted to just migrate the latest revision. We are a small shop, and it sounded like more trouble then it was worth to preserve the entire history.
I still made a big mistake though. I just took all our source and added it to Git, just like it was setup in subversion. We have over 1.5 GB of source including game assets such as images, sounds, and puzzle data. This is when I learned that GitHub doesn't recommend repositories over 1GB.
I learned firsthand how painfully slow it was to pull down a new large repository, and I was also worried that we would get flagged by GitHub for having too large of a repository. I also found I would occasionally get an error downloading the new repository and would have to start over.
The solution was to breakup the old subversion repository into several smaller repositories and submodules. I haven't had any issues with these smaller repositories.
I decided to break up the old single subversion repository into several smaller repositories. Each iOS app we make has its own GIT repository, and we use submobiles for shared components.
This is an example of the submodules used for Hashi, a new App we are working on.
What's nice about using submodules is that the parent project references an explicit revision of the submodule. So if a submodule is updated in a different project, it won't break the current project. This allows you the time to upgrade the project at your own connivence.
One thing we learned is that you have to be a little careful when adding a submodule to your project through SourceTree. By default SourceTree was adding the user's login to the submodules URL. This of course causes issues for other people trying to work with the submodule.
You just need to remove the user's login from the URL. If you forget, you can manually change the .git/config to reference the correct submodule URL.
It took me a weekend or two before I started to understand Git. I'm still far from an expert, but I am getting more comfortable with it. One of the sites that really helped was from Mark Lodato and his Visual Git Reference. Stuart Ellis also has a really nice basic getting started guide to using Git. And finally the must read Git Reference on Branching and Merging.
Please feel free to follow me on twitter at @fivelakesstudio. I would love to hear about your experiences on using or switching to Git. Let me know if you found this useful.
Thanks for reading and be sure to visit us at Five Lakes Studio.
Picking a Hosting Provider
Given Ken and I work together on projects we need a version control hosting provider. We currently use Beanstalk for subversion, and we have been very pleased with them. However, I decided to take a look at the available options. I took a serious look at GitHub and Bitbucket. I opted to go with GibHub for our main git repository. I really liked its interface and how it links your personal account to your corporate account. Plus it has a big user following. Several reviews I read also talked about GitHub being more performant and a step ahead of Bitbucket. However, that info could be a bit dated by now.
We opted for GitHub's $25 per month plan for 10 private repositories. However, I also created a Bitbucket account as they have free unlimited private repositories. I'm using bitbucket to host paid for 3rd party assets, and I'm using GitHub for our source.
GUI Tools
While lots of people use the command line to manage Git, I prefer having some nice GUI tools for my day to day work. There are several tools out there, but I ended up going with SourceTree. It seems to be the most complete tool for managing subversion repositories. I also used GitHub's tool for awhile to get up and started, but SourceTree feels like a more complete and powerful solution.
Migration
I decided not to do a full history migration from Subversion to Git. I opted to just migrate the latest revision. We are a small shop, and it sounded like more trouble then it was worth to preserve the entire history.
I still made a big mistake though. I just took all our source and added it to Git, just like it was setup in subversion. We have over 1.5 GB of source including game assets such as images, sounds, and puzzle data. This is when I learned that GitHub doesn't recommend repositories over 1GB.
I learned firsthand how painfully slow it was to pull down a new large repository, and I was also worried that we would get flagged by GitHub for having too large of a repository. I also found I would occasionally get an error downloading the new repository and would have to start over.
The solution was to breakup the old subversion repository into several smaller repositories and submodules. I haven't had any issues with these smaller repositories.
Submodules
I decided to break up the old single subversion repository into several smaller repositories. Each iOS app we make has its own GIT repository, and we use submobiles for shared components.
This is an example of the submodules used for Hashi, a new App we are working on.
What's nice about using submodules is that the parent project references an explicit revision of the submodule. So if a submodule is updated in a different project, it won't break the current project. This allows you the time to upgrade the project at your own connivence.
One thing we learned is that you have to be a little careful when adding a submodule to your project through SourceTree. By default SourceTree was adding the user's login to the submodules URL. This of course causes issues for other people trying to work with the submodule.
You just need to remove the user's login from the URL. If you forget, you can manually change the .git/config to reference the correct submodule URL.
Conclusion
It took me a weekend or two before I started to understand Git. I'm still far from an expert, but I am getting more comfortable with it. One of the sites that really helped was from Mark Lodato and his Visual Git Reference. Stuart Ellis also has a really nice basic getting started guide to using Git. And finally the must read Git Reference on Branching and Merging.
Please feel free to follow me on twitter at @fivelakesstudio. I would love to hear about your experiences on using or switching to Git. Let me know if you found this useful.
Thanks for reading and be sure to visit us at Five Lakes Studio.
Subscribe to:
Posts (Atom)