Tag: Refactor

The Wonderful World of Computer Graphic User Interface

As WWDC 2013 is over, some of the respectable opinion leaders share their thoughts on iOS 7’s new look. I would like to share links to their posts:

I admit, I’m quite biased in selecting these posts, having positive perspectives.

Surprisingly, there are some common understandings I could find, and have come up with myself, about iOS 7’s new look. Though I’m not a professional designer, or an influential leader like the ones above, I think it won’t be too bad to write one more post about iOS’ User Interface.

Representation by Animation: Until recently, objects or ideas have been represented by visualization. However, instead of bringing full detail from the looks of the objects shown in the real world, iOS 7 chose to use subtle or obvious animations of the objects, or about the ideas as the essential representation method. Please watch the video about Apple’s Design Intention, and recognize how different animations have been used to identical circular dots, to represent many different objects and ideas. This shift can be a great opportunity to those who believe in the apps to be more dynamic and alive, and a great challenge to those who are so used to draw beautiful but only static images.

Content Supremacy: iOS 7’s extremely minimal buttons and labels remind us what we’ve been forgotten; that the app’s main content must have full attention. If pixels or focus inside the device’s screen cannot be shared, so fighting between the main content and user interface controls cannot be avoided, iOS 7 voluntarily yield user’s attention to the main content, by making the controls so thin, translucent & borderless. Because they occupy so little area or look so simple, they can help the main content to be stood out automatically. However, what should not be misunderstood is that, the limitation on the controls can be ignored if they are parts of the main content.

Space Telescope: It’s not that easy to bring fluid transitions between views, but iOS 7 provides new methods to help the developer to implement them as easy as possible. I think it is to encourage the device’s screen to be utilized like a telescope showing one area of much bigger space, which includes more contents yet to be shown, until the device’s screen is looking toward them. The concept of panning & zooming from scrollable views have become more adoptable into view transitioning. Personally, I really like this. (Don’t know how to express in clearer form but…) This is to motivate the apps to bend more space and time, which is no real world medium will ever be able to do.

Still, it is Beta 1. I wonder how the end result will be for the look of iOS 7. But, at least for now, the heading of this exploration is showing the glimpse of the wonderful world of computer graphic user interface.

Advertisement

Fully informed and experienced decision

My comment for “Why I Don’t Use Interface Builder”: http://blog.teamtreehouse.com/why-i-dont-use-interface-builder

IB is about Organizing, not about Replacing. IB is a tool, not a regulation.
Once you know the limits of IB and developed good programming habits, IB can be extremely useful.

I saw too much terrible spaghetti codes, which could have been helped by adopting MVC principles and knowing the life cycles of UIViewController & UIView instances.
As a way to help those developers to learn about the principles, I show them how to complete a project using IB and later replace it using only codes, to help them to realize the limits of XIB files and see how whole structure is preserved, to show the real reason for using IB: Separating codes.

And once VIEW components are separated from others, I point out patterns or repetition, which are just configurations at loading of the instances.
Other than iteration, they are not so easy to be solved creatively and quickly, without taking precious seconds, minutes, or hours.
Also, there are more important tasks for fulfilling the requirements of the app, than tasks for calculating frames for labels.

Unless you like it (I saw some people who like it), it’s smart or even necessary to use a tool which was developed to avoid working mechanically. Fortunately in Xcode, we have Interface Builder.

Depending on the characteristic of the projects, the decision to use or not to use IB is totally up to the developers. When they decide not to, I hope it’s fully informed and experienced one, instead of one caused by estranged or uncomfortable feeling toward IB.

Don’t punish Yourself

It’s given as a PUNISHMENT to a student to write sentences REPEATEDLY on a blackboard.

If you are not careful, it’s quite easy to REPEATEDLY paste copies of identical code snippets. Not using iterative methodologies and not trying to find algorithmic solutions, is like let yourself to be in the state of uncomfortable incompetency, which is a PUNISHMENT.

Avoiding Difficult Errors

The errors do happen. It’s impossible to write error-free lines of code at first.

If it has to happen, then I would like it to be easily searchable, and have been happened to others, and publicly documented, preferably with right solutions.

Often errors are caused by attempting to do something new after learning about changes in methods, or when adopting external source codes.

However, the difficulty in fixing the errors may be eased, if your new attempts are based on rigorously reviewed official documents, or widely used & time-tested open sources. Unless, you were doing extremely strange stuff, most of the errors you will encounter usually already had happened to others, and fortunately solved and documented for you.

Or, if your error is absolutely new one, you have the right (or responsibility) to expose it and ask for attention from others. Because the error is caused by your attempts based on the official documents, there is no way fellow developers who read the same documents to ignore the situation. It does matter to them. And they will join you to fix the problem, making the process relatively easier than doing it alone.

If what makes fixing the errors difficult is because they are strange to you, and you have to do it by yourself, improving the condition of the root causes can help you avoid the difficult errors.

PopToo is updated to version 1.3.5!

And changed its name to PopToo Classic.

[iTunes Link: http://itunes.com/apps/poptoo]

As a preparation for New PopToo, this Classic version has implemented potential iCloud functionality. It’s not yet operating, but next updates will bring ways to utilize iCloud storage, so you can migrate your history to New PopToo with no problem.

Currently, New PopToo is being developed by totally rewriting it. The main goals of New PopToo are:

  1. Focusing on Personal Use: Instead of requiring the user to connect to his or her social network to use PopToo, it will focus on being an utility which is great for geotagging user’s favorite music. Of course, sharing through social networks will not be gone, but be upgraded instead.
  2. Improved User Experience: New PopToo will be more handsome to look at, more interactive to touches. After all, iPhone and iPad has been touch centric devices and New PopToo will take more advantages of them.
  3. Adopting latest methodologies in iOS development: After being more informed about strong user acceptances in latest iOS versions in general, I am confident that us iOS developers are free from supporting legacy versions, and the cost of such freedom is tremendously inexpensive.
  4. Optimizing essential performances: The fundamental software problems including error handling, concurrent processing, and database architecting will be thoroughly revised. As a student of computer science, it’s my responsibility and privilege to look for the right solutions and learn to implement them to bring the best performance of PopToo.

By the way, I was able bought a ticket to WWDC 2012. It will be a great experience for me to be able learn new ideas and meet great people, I believe.

Enjoy PopTooing your favorite music!

[Korean] About my comment on the book, ‘Real iOS Programming without Interface Builder’

This is the comment I left at following URL: http://www.acornpub.co.kr/blog/406  ‘인터페이스 빌더 없이 하는 아이폰 리얼 프로그래밍’

It’s about questioning the intention of the book about doing iOS development WITHOUT using  Interface Builder. It’s written without reading the book yet.

I’m a strong proponent of Interface Builder and its usefulness, and my comment was about that not using the Interface Builder may not be useful for those who need to read this book, who may be new to programming. And ironically to the author’s intention, it may not be able to help creating the application which should be easily maintained and expanded.

(내용을 읽지 않고, 별도의 프로그래밍 관련 주제의 댓글입니다. 소개글만 읽고 적은 것이므로. 책에 대한 평가로 오해하지 말아주세요.)

좋은 책이 나온 것 같습니다. 인터페이스 빌더’만’ 쓸 줄 아시는 분들에게 무척이나 유용하고 의미있는 내용을 가지고 있을 것이라 생각됩니다.

정교하고 디테일한, 100% 통제를 해서 모든 요소들을 일일이 다 챙기는 것이 중요한 프로젝트라면 당연히 코딩으로 VIEW 또한 손수 다 그리는 것이 좋을 수 있습니다.
또한, .xib 은 일종의 XML 로서 parsing 과정을 거쳐야 하기 때문에, 0.001 초라도 아껴야하는 경우에는 분명 사용하지 않는 것이 맞습니다.

하지만, MVC 분리법에 대한 충분한 이해가 되지 않은 초보 개발자, 실제로 응용해본 경험이 적고, 그 가치를 제대로 이해하지 못한 개발자들에게는 잘못하면, VIEW-CONTROL-MODEL 에 속하는 코드들이 우후죽순 막 섞히는 결과물을 내게 만들기도 합니다. 마감날짜가 급한 경우에는 더더욱 유지보수에 문제가 있는 (앞으로 문제가 생길) ‘위험한 코드’를 만들게 되지요.

이렇게 되면 소개글에 나타난 대로 유지보수에 탁월한 해결책이 되어주지 못하게 됩니다.

분명 하드코딩은 중요하고, 어떤 개발환경도 반드시 이것을 가능케 해야 합니다. 하지만, 이것은 과거의 생산물이 가진 생명력을 연장하는데 좋은 것이지, 미래를 위한 혁신적인 결과물을 만드는데 장애가 되는 것이라 생각합니다.

그래서, 혹시라도 미래를 위해서 일해야할 초보 개발자들에게 잘못된 습관을 가지게 하거나 자칫 혼란을 주지 않을까 하네요. 컴퓨터가 할 수 있고, 컴퓨터가 해주는 것이 훨씬 더 좋은 일인데도 불구하고, 단지 자기는 이렇게 가르침 받았고, 이렇게 하고 싶다는 이유만으로 하드 코딩을 고집하는 것은 미래에 대한 좋은 준비자세가 아니라고 생각합니다.

또한 단지 코멘트를 많이 남기기 위해서도 좋은 이유라고 생각되지 않네요. 코멘트 대신에 코드 그 자체로 모든 내용을 표현할 수 있다면 제일 좋다고 많은 분들이 얘기하시는 것 같던데.

반대로, 인터페이스 빌더를 쓰면 그에 대한 설명을 구구절절 코멘트로 어딘가게 남겨둬야 하니, 아예 코멘트 없이 코딩을 하기 위해서라도 하드코딩을 하는게 좋다고 하려 하신 거라면, 적극 동감할 수는 있습니다.

책의 내용은 분명 추정컨데 회사내 베테랑 개발자들에게 무척이나 도움이 되겠지만, 책없이 공부할 줄 아시는 그분들에게 정작 책이 필요하지 않을 것도 같고요. 왜 그동안 이것을 공개적으로 다룬 책이 씌여지지 않았을 지 좀더 냉정한 고민을 하셨기를 바랍니다.

당연히 그런 고민을 하셨다면, 어떻게 하면, 인터페이스 빌더의 장점과 하드코딩의 장점을 융합해서 양쪽 모두가 가진 탁월함을 같이 쓸 수 있는 방법도 책에 써주셨을 거라 믿습니다.

이런 목적으로 두마리 토끼를 다 잡는데 유용한 내용을 쓰셨다면, 이런 책이 다른 곳도 아닌 한국에서 한글로 먼저 출간된 것에 엄청난 자부심을 느끼셔도 좋을 것 같습니다.

Optimizing PopToo’s performance: Found the cause which can’t be removed

Lately, I’ve been doing some tests on my iOS app of PopToo project to optimize its performance.

The main situation I wanted to solve was when the PopToo is restoring to be Active from being in Background, it freezes for at least a second before starting to respond to user interaction.

I’ve examined a few areas and these three areas came to my attention: saving transformable objects in Core Data model, delayed selector callings for dismissing certain views while in background, and activating different accuracies for Core Location service. I tested them by eliminating each one.

Initially, I thought saving transformable objects in Core Data was the main cause. As recommended by many, I changed it to store numerical data types. Though it could save some storage space, which may positively affect migrating to new database scheme in the future, it didn’t solve the problem of experiencing freezing.

Next, delayed selector callings for dismissing certain views were dealt by simply excluding them to be used simpler without delay. Which had started for dismissing keyboards when PopToo iOS App goes background, gradually became too complicated, and currently requiring to be refactored anyway.

For saving device power, PopToo changes Core Location service accuracies to be Best if it’s Active, or ThreeKilometers if it’s in Background. And this is the spot where PopToo’s performance is significantly lagged. Core Location seemed to do a lot of critical jobs, that are important enough to cause freezing for a while, when it’s activating stronger accuracy.

Though a cause of performance lagging was found, I couldn’t develop ways around it yet. Since it’s very important and useful way to save device power while using PopToo’s Auto Check-in features, this accuracy changing can’t be removed.

Also, PopToo’s lagging interval seemed to get longer as it’s kept running until being terminated. This means there can be other reasons too, in different areas. I’m guessing it’s related to memory management.

Guess my search is to be continued.

%d bloggers like this: