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.
As a learner of programming, you may feel stressed and uncomfortable, trying your best to maintain control over the machine, not to be controlled by it.
There are too little time to complete the assignment. Your mind is not clear enough to come up with the best structure of different classes. Inheritance, polymorphism, DRY, MVC and all other essential concepts about quality programming are just ideas without visible lines of codes.
Even if you could finish your work on time, it’s quite painful to see resultant chaos in your own codes. You don’t like your own work, knowing every line in it. And this is a good thing.
Being sensitive enough to realize inefficiency and incompetency in your own work, even if no one criticize it, is a great attitude, especially if you are a beginner. Congratulation! Make sure to keep it as sensitive and sincere like that.
Until you become a true master of programming, who can bring undeniable great architectural solution without taking too much time and resources, please don’t try to avoid or ease the pain for producing quality result.
It’s necessary to feel the inefficiency of scattered snippets within your codes. You need to experience the frustration of attempting to change a small thing, repeatedly about thousand times. After experiencing this, you will never forget the critical importance of DRY principles and will force yourself to learn how to use global variables and methods, apply proper hierarchical relationship among classes. Soon, it will become natural to you as you become a better programmer.
However, it you let yourself to be insensitive to pain while programming; e.g. listening to music or copying & pasting mindlessly; you will lose the opportunity to see the need to improve. Simply for the sake of finishing the work as soon as possible, you will just pass by the situation which may teach you very important principles.
Such insensitivity will bite you back, as you maintain the chaotic structure, slavishly patching the effects without fixing the causes. And finally, you will give up, unless you can start all over again.
Recently, I have been enjoying the opportunity to practice implementing concurrency in my software engineering.
Following iOS’s own concurrency programming guidelines, I could develop some confidence in designing the workflow from the initial stage to achieve optimal performance.
By separating works into two types; for UI & not for UI; I have been able to keep queues of operations to be as simple as possible. Also, due to obvious convenience of using Block programming with iOS SDK, I could be able to actually see where asynchronous queues branched out, and merged back, right within the scopes of codes.
Being able to keep tracks of these operations was quite exciting for me, since I used to have great fear in adopting concurrency. But the real issue I have to fear should have been lack of real performance and difficulty in seeing the workflows among the objects.
Fortunately, learning more about the convenience of using NSOperationQueue and the basic criteria for deciding when to branch out and when to merge back, which is; “Are these operations for UI or not?”, I could see what’s actually going on much clearer than ever.
It has been a good case for me to realize it’s not enough to memorize the list of methods, but often it’s more important to know when and where to use them appropriately.
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:
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!
PopToo uses Core Data extensively. However, the way it uses fetched objects is not good for memory management, especially for an app like PopToo, which is focused on running background.
Unlike what’s often recommended, PopToo simply uses a few number of NSMutableArray instances to manage fetched objects from Core Data. Due to the original design structure for sectioning these objects into UITableView based on time or distance, I have postponed to use NSFetchedResultsController instead.
Though the design has worked as I intended, using NSMutableArray wasn’t the right way. As PopToo is running background, new objects will be constantly added, when new stream of PopToo Friends’ check-in data is downloaded and when the user checks-in his media information. Inevitably, memory allocation for NSMutableArrays will be grown until the user terminates PopToo, or the device system does. And as they grow, performance of PopToo is affected, which is more visible when it’s restoring to be active from being background.
For next update, I will refactor PopToo’s workflow to be more suitable for running background. Memory allocation will be strictly minimized, instead fetching objects from Core Data will be refreshed more often. I am fully aware that fetching requires some time and may not be the right solution for better performance, but I am confident it will make PopToo’s lagging issues to be less visible, enhancing the user experience.
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.
fXceed.com 