Alterplay

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 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?

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.

• 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

We’ve released new product recently. It’s called Debty. It helps to manage debts of your friends. There is a banner at the right top. If you want a promocode please request it on the twitter.

The goal was to develop something easy to use with limited features. Developing it we’ve got some useful ideas I want to share.

Design

The very custom design was also required. After a few hours of research Jeans style was chosen. I hope you’ll like it.

Beside it’s really hard to develop and support custom designs, now I see it’s too custom. App design should be more simple and less like “cartoon”. Too much details, textures and volumes are pleasure to look first 3 times, but then they detract from the main thing – functional parts.

No matter how much your design is custom or unique or extravagant, you have to abide by the law of HIG (Human Interface Guidelines). It means your controls should be right sized and placed, e.g. buttons in the UINavigationBar, and you may still use the same navigation principals with UINavigationController or UITabBar. etc.

OK-message sucks

As less OK-messages you have, better your application is. Means you shouldn’t notify user “Your tweet is posted. Press ok to continue.” – use sound notification instead or “Profile is saved” – show some small animation in saved block instead.

So just take every OK-message from your app and ask “is it really required?” and “How could I notify user without OK-message?”. You’ll see how easily you invent some new approaches. Nobody says it’s easier, but worth that.

I think that’s a different between User Interface and Human Interface.

So please look this next short. There are some tiny animations which we are proud of.

• “Enter an amount” and “Select a debtor” OK-messages are replaced by soft vibration of inputs
• View and Edit views are combined in one view which transforms with animation to one state to another. Yes it’s like Contacts.app does.
• Every date has human representation like “Today”, “Tomorrow”, “3 months delay”, “refund in 8 days”. it’s changed on the way while editing.

The best UI is absence of UI. It’s so much natural to not require time for adaptation.

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial; min-height: 16.0px}

Logging is very useful and powerful tool. All iOS programmers knows about such great method as NSLog(NSString *format);

#ifdef DEBUG    #define LOG(...) NSLog(__VA_ARGS__)#else    #define LOG(...)#endif

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial; min-height: 16.0px}

#define LOG_LEVEL_MOST_IMPORTANT 1#define LOG_LEVEL_NORMAL 2#define LOG_LEVEL_COMMON 3

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}

+ (Void) log: (NSString *) message level: (short) level;

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}

#define LOG_LEVEL_MOST_IMPORTANT 1#define LOG_LEVEL_NORMAL
2#define LOG_LEVEL_COMMON 3 @interface Log : NSObject {} +
(void)log:(NSString *)message level:(short)level;

@end

#define LOG_LEVEL_NOTHING 0 #ifdef DEBUG    
#define CURRENT_LOG_LEVEL LOG_LEVEL_ MOST_IMPORTANT#else
#define CURRENT_LOG_LEVEL LOG_LEVEL_NOTHING#endif

+ (void)log:(NSString *)message level:(short)level { if (CURRENT_LOG_LEVEL >= level)
NSLog(@"%@", message);}

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica; min-height: 17.0px}p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}

[Log log:@"test message" level:LOG_LEVEL_COMMON];

[Log log:@"Warning! Server not response!" log:LOG_LEVEL_MOST_IMPORTANT];

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Arial; min-height: 16.0px}