PopToo 2017 is Coming Soon!

Dear PopToo Friends!

Thank you for staying with PopToo ever since 2011 and 2014!

If you were wondering what has been happening ever since, why PopToo didn’t explosively made new progresses for too long, well, it was all because of the main developer (@petershine) being a busy graduate student since 2015. The developer will tell you more about the life of being a graduate student in later time.

Since the developer had to do his best to balance proper amount time for different jobs, it has taken too long to re-start New PopToo. But as graduation is coming, PopToo evolution can re-start again to excite all PopToo Friends with new evolution! Also, this re-starting is the significant part of Master’s Project for graduation credits.

The main focus of PopToo 2017 will be advancing social interaction among PopToo Friends. Intended as the original concept since 2011, location based song matching for making new friends and previously geocached song recommendation will be implemented.

Within about 7-days, new PopToo updates will be announced and distributed regularly via Apple’s TestFlight for iOS
If you don’t know what it is, it’s simple beta app distribution system under Apple’s management.
Once you downloaded the beta, just Geotag and Share Your Music!

EMAIL UPDATE SIGN-UP: http://eepurl.com/F5YQP

Advertisement

Learning to Adopt Concurrency with Confidence

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.

Do your best to spend time for the Real Work

Recently, I had to work so much time on one element of the product, requested by the colleague who was not completely sure if the application was perfect enough for her to think that the product was alright to be released.

At the end, we have found that perfecting the element was impossible since it relies on the external conditions like network status. I had known about this, but I had to show it to her to convince her that it was impossible. She usually don’t understand about software limitations without actually seeing them.

I don’t disrespect perfectionism. Sometimes, even I can see myself spending so much time for just a few things of whole product, to satisfy my purposes for them.

However, it’s false to consider getting the perfect result is directly related to and only possible by working a lot of time on it.

And if such hours were spent for the sake of reenacting already known and proven limitations, you should accept the fact that you just wasted precious time which could be spent for the real work.

I am trying my best to use my work hours for the real work. But it’s irritating when it’s not possible because of incompetencies of others.

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.