Archive for the 'Open Source' Category

09 DecOpen source ShareKit 2.0 is ready to use

A few months ago I suggested ShareKit community to create ShareKit 2.0. The only reason was ShareKit is highly demanded and the original author had no time to develop the project — last commit by Nov 22 2010. There are 289 forks and tens of ignored pull requests and many–many issues generated by community. All these had proved situation was deadlocked.

So I posted a suggestion and sent a few private messages to most active participants. Fortunately some good people found idea worthy. ShareKit/ShareKit was found as a community and just gathered core team defined Policies.

4 months later. Read more…

18 JulA few tips on how to use open sourced ShareKit easily

Fork me on GitHubJust a quick note on How to use ShareKit open source library a little bit better.

0. Settings for Social Networks
Getting ShareKit first time you need to setup social networks. Nothing difficult because it has so good commented guide in SHKConfig file. I use Git and made a public fork of ShareKit for the Alteprlay. So now when I push back changed code of ShareKit as a submodule every one can see it. And my settings also :)

Despite that a solution is so obvious I still want to share it because it could save you hours to cut your private settings from public Github commits.

Just copy SHKConfig.h file from the lib directory to your source files and remove original one from the project. Then do anything you want with settings and it will always be in your private repository.


1. Activate URL Sharers for text sharing

In the Forismatic app we need to share quotes via Google Reader and make possible to copy quote to the Pasterboard. Both features are disabled by default.

There are several boolean methods in SHKSharer that control whether a derived Sharer can share Text, URL, Image or File. So we can find +(BOOL)canShareText and return YES instead NO. It just works.

Each time you update ShareKit library not depending you use Git or whatever you need to change this parameters again and again. So the right suggestion is Obj-c Categories. Example for Google Reader:

The same way you can deny or allow any service for any content.

3. Support both localization for the target app and ShareKit

An app may have only one active Localizable.strings for each language. ShareKit provides localizations so it has many such strings.

Again, in the Forismatic app we have own localizations and own *.strings. I was surprised when found they compete with ShareKit translation strings. The active one is that one which is last added :)

The simplest solution is just copy those translation content you need to your *.strings and it’ll work. But again it’ll be hard to manage updates, etc. So I suggest more accurate solution.

  1. Rename all ShareKit’s localizations to LocalizableShareKit.strings
  2. Find SHK.m and change NSLocalizedString(key, key) to NSLocalizedStringFromTable(key, @”LocalizableShareKit”, key)

So now it doesn’t compete with your own localizations and gets translations from renamed *.strings.

Don’t forget to push it back to your fork and merge in right way each time you update the lib.

4. Next big thing

The next thing I want implement is to change sharing text depending on which Sharer call it. For example,

  • if it’s Email Sharer I want to attach AppStore link after a quote
  • if it’s Twitter Sharer it may vary of how long a text quote because twitter can contain 140 chars only. So if it’s more than 140 then it’s better to cut the quote and attach a link to this quote.
  • etc.

11 MarGIT will organize your development process

This long weekend I seriously decided to dive to Git. Everybody heard about a distributed revision control system, but most were afraid to try this Linus Torvalds child. I was one of that guy, despite the fact I used more that 10 GitHub projects before and watching for many projects.

Git

  • Yes, it’s hard to start and not easy to use.
  • It’s not like SVN, but really about another way to think.
  • Sometime processes seem too complicated, but after a few days everything looks reasonable.
  • There were two reasons I kept going to this for a while.

Open source 
More and more project I use from Github. Sometimes I improve them, but don’t “commit” back to the main repository. So morally I wasn’t paying tribute to developers and the community (beautiful community graph). As well in practice I have problems with updating modified sources with new one from GitHub. No chance for merging. It’s just unnatural.

Own source
The second problem I felt for past months is about organizing own classes. Since we started to work together as a team It’s become really actual to build a common repository with reused classes.

SVN
I’ve been keeping all my sources under SVN during last two years. It’s included to my hosting plan. Easy to commit if no hard merging. Good Mac client – Cornerstone.
SVN to Survive

But now it’s a discomfort in collaboration inside the team and over the #iphonedev community. For example, two weeks ago we created 3 (THREE!) version of the same application to verify ideas. It was about MGSplitViewController from GitHub. Moreover after we found a solution it’d be better to commit changes to the GitHub, but didn’t do that. Yes, it’s our own fault, but tools have to encourage to go right way. Now we have two different own splitControllers in two projects. It’s representative, isn’t it?

After that I read an article in russian where guys described how they faced very similar problems and tried to use SVN further.
Use Git
  • I started to read about GIT from several articles. It helped me (ru) to understand what problems people have and how they solve them. Read a few in russian.
  • Then I started to try. After many hours of experiments I felt a lack of theoretical knowledge, so I found a good book – Pro Git. It’s translated to many languages, e.g. russian.
The plan

  1. Move common Categories and low level classes to common repository. E.g. AvatarManager, Settings, LocatorSingleton, etc.
  2. Determine and move base classes to the repository. I always had a few, but they migrate from project to project and have 10 different versions. This wrong way of source organizing makes more and more discomfort. Examples: BaseViewController with messages, delegates and activity indicator; ListViewController, SearchViewController, etc.
  3. Then move more powerful Controllers that are very similar and used more than twice. E.g. SplashController, SynchTableViewController and NearOnMapsController. Such controllers should be refactored and tested. That’s why it’s actual for active project only. And it’s better to extract them during a real project or refact two old projects simultaneously.

The challenge is to support own lib with numerous branches, often pushes (commits to the origin/master) back and keeping other branches fresh. The terminal is only way to manage this process because it’s easy to be confused by a list of 5–10 branches of one lib for different projects, if you see them all together in a GUI client. Maybe we’ll think about automatic update mechanism.

Git practice
The first an easy but completed thing I did was a NSTimeZone-Localization update. I read through my RSS feeds and found a Cocoanetics’ post about open source project for NSTimeZone translating. Sure I could translate it to russian. So i did that and push my update to my fork, then made a Pull Request. A small but useful lesson.
What’s next?
Now I am refactoring active Alterplay projects starting from the freshest one. I am convinced that it became easier to integrate GitHub projects to existing SVN project.
Next steps are:
  • learn to work in Git team and product style and test knowledge on next customer project
  • determine more common classes and organize Alterpaly library (APLib) as a GitHub private project
  • to convert inner SVN projects to GitHub and implement Git’s submodules
  • open the Alterplay Lib to the iPhone development community part by part
I’m glad to see how sources and then dev process become more organized with right tools.