Developing New PopToo

As PopToo, specifically the Classic version, is taking a break, New PopToo is busy being developed.

With the strong desire of the developer to try latest iOS methodologies, slowly but steadily, new looks have been tested and new ways to make the experience more enjoyable have been evaluated.

PopToo's New Look

Above image is showing not yet finalized look, but the main idea is to use the map as large and prevalent as possible.

Previously, I posted about my big hope for Google Maps iOS SDK. Without being actually disappointed at it, I have realized what I really needed for PopToo’s map.

Though Google’s map is great for showing regional information, the images are still bitmaps. For PopToo’s use of the map is focused around adding annotations, support for drastic zooming or scrolling, with better animation and rendering rate is more important.

Also, Google’s APIs are not really free. Until I can find the right strategy for PopToo’s growth, I can’t help but to delay my final decision to use Google Maps iOS SDK.

For now, the previous plan has been changed to use iOS’s original MapKit. Even though I recognize the many disadvantages of current MapKit, rather I am willing to make PopToo to complement it with the great features.

You can see them soon. Hope you would like them.

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.

Sensitive Programmer

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.

Google Maps iOS SDK

UPDATED: Lately, my opinion about Google Maps iOS SDK has been changed. Quite drastically, after experimenting more with Apple’s MapKit, and having much clearer about the requirements of PopToo, adopting Google Maps may stay optional for a long time.

Google Maps iOS SDK has been announced, and developers can register to receive API keys: https://developers.google.com/maps/documentation/ios/

I personally have been anxiously waiting for this announcement, believing this SDK should come before the end of this year.

While struggling with myself in making enough time to develop new PopToo, or even to upgrade PopToo Classic for new 4 inch display, I can’t help but suspecting if Apple’s MapKit is really the right choice for PopToo. Naturally, I had to believe Google Maps should be available for developers as SDK, and now it’s realized.

Google Maps’ ubiquitous accessibility including web browsers, makes the service definitely superior to others by itself. Also, this ubiquitous accessibility fits great with PopToo’s plan to expand toward web application.

I’m still reading the documentation. I’m only confident that available features in this SDK will be useful for new PopToo.¬†This announcement alone was able to re-invigorate my motivation to accelerate developing new PopToo.

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.

Can App PREview Process be helpful?

Recently, our team has submitted an iOS app to the App Store to be reviewed.

Unfortunately, due to Apple’s own policy, this app was rejected and we couldn’t release it.

Personally, I have known this would happen. What this app tried to do was something questionable, at least in its intention, even if there is no technical violation.

Our team’s strategy was very simple. If Apple didn’t publish anything against about what this app tried to do, we could challenge Apple to accept the end product. If Apple didn’t say NO publicly, we should try it. That was the argument of the team leader.

However, Apple’s decision after reviewing was solid and there is no way we can reclaim time we spent to develop this app. The only comfort we could get was that Apple’s reviewer himself also felt sorry for us, recognizing it’s not a technical violation but just a political issue.

I just wish we could have known about Apple’s policy on this long before designing and developing the app. At least for me, if I could present public documentation about this matter, maybe I could persuade the team leader not to waste our time.

Or, it could be so much better if there are people in Apple’s side, who may answer our questions, BEFORE we start designing & developing something. I wonder if it’s helpful to have PREview team, like REview team.

Of course, there are a lot of instructive materials, teaching us what should we consider when developing an iOS app. But I just wish there is an actual Apple Genius whom we can talk to about very special and rare idea of ours, we just can’t help but to try out.

It’s just wishful thinking of mine.

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.