Visn 2.0.1, The Overhaul, Part 3: Listening for Bugs

One thing that users will not respond well to is a sluggish experience. When Visn was first released, it didn’t run well. It was a buggy box with a pretty shell and we learned from that. Granted, some things got in the way before we could get a fresh new build out the door, many mistakes were made on my part in not pushing out at least a smaller point release that fixed critical game breaking bugs. I believe this cost us many users and we won’t be making the same mistake this time around.

The Reports

When I was first learning about iOS, one statement seemed to keep coming out, “Pull your crash reports”. A crash report is just what it sounds like. When an application on your device decides to take a dump, it records exactly what led up to that crushing moment. Based on your preferences on sending Diagnostics & Usage to Apple, you may then send it to them. From there, they distribute it to developers of the app so we can bring it into Xcode, symbolicate them and find out just what the hell happened. We can access them via iTunes Connect, the portal to the App Store universe that handles everything from sales to managing apps.

Despite the importance of retrieving those reports, I subconsciously decided to ignore it and avoided the crash area altogether. Once I finally did, I was shaken to reality that I had not put in the work that users expect when purchasing an app. They expect a level of quality on par with Apple and, most importantly, they expect you to fix what is broken. Reports echoed exactly what users were saying in reviews. Visn was broken. Fix it.

Focusing on Quality

Part of 2.0 and 2.0.1 was not only to focus on these crash reports but to improve our testing/QA process. That’s where tools like Testflight came extraordinarily in handy. If you are developing apps and aren’t using this tool, you’re missing out. Before, I was manually installing new builds on Greg and JT’s devices. Now many developers out there are /facepalming because there was obviously the ability to go the ad hoc route without using fancy tools like Testflight. Clearly I was still rounding out my knowledge and, in the month after Visn’s release, I was working with a studio in town that gave me more insight into effectively distributing builds for internal testing. That’s where I then /facepalmed myself, of course.

Thanks to our better process, we were able to catch a lot more bugs, crashes and issues than before. Greg, JT, even my wife and I started slamming Visn from all angles, it proved to bring me great frustration but, I knew, that each bit of pain I felt in a bug/crash being found was one less the user would have to deal with. Still, the app has a long way to go to become exactly what we envision. The roadmap excites us and keeps us moving forward.

That’s also where you all come in. Our userbase is and has been providing invaluable feedback that helps us identify what we are doing right and what is just flat out not good. So keep sending us your thoughts, be it email, tweet or iTunes review.

By javier| March 16, 2012

Visn 2.0.1, The Overhaul, Part 2: Memory and Speed

Apple provides a robust set of tools to help us optimize an app to levels I was never used to before as a web-based developer. For those that don’t know, my roots were born in a combination of traditional art training (illustration to be specific, traditional animation/graphic design/film to not be specific) and what another hobby I had. Flash websites. There’s an entire article just waiting to be written about that, but I’ll hold off, and I’m certain you’ll thank me for it.

Now back to those tools, most notably, Instruments. It’s an incredibly powerful and amazing program that, when wielded properly, can bring down colossi along with entire galaxies. Unfortunately, I haven’t yet become that proficient and, even if I did, I think I’d hold off on the destroyer of worlds level. This is another part of my maturity on the iOS and Xcode platform that has continued to flourish and has helped in our efforts to make Visn what you all want and hope it can be.

The Footprint

The most embarrassing thing about releasing 2.0 is that, from a development standpoint, I chose to focus more on making it iPad while fixing crashes/bugs reported by users along with Greg & JT. It was great but the entire time during those late night shifts, I could feel a little poke telling me I was missing something. After the release, a good friend of mine who had been eagerly awaiting the iPad version downloaded it on his first generation. His first thoughts brought the realization rushing to me as fast as a sledgehammer crushing through a pane of glass. “It keeps restarting”.

Shit. I’ve done it again. Another release had gone awry and, this time, it would cost us even more users that managed to hang on this long, approximately 5 months after the first release, in hopes that we would not let them down.

For the first month after release, I was diagnosing and testing everything I knew how to see what I could change or improve, studying the entire codebase again to see what areas were not as efficient as they could be, etc. After mucking around, I found some mediocre solutions but nothing that really made a big difference. What was the memory footprint of Visn in 2.0? Well, according to Activity Monitor, it was sometimes running as high as, I really hate to admit this, but using around 180 MB (this primarily sky rocketed in list view, which will make more sense in a moment).

The first generation iPad has 256 MB of RAM and the second has 512 MB. First, an image browsing application (or any application) using that much memory should be held to criminal charges. Excessive memory use might be a good name for it.

When multitasking was introduced, Apple brought about a system that was meant for users not to tamper with. Multiple applications could be suspended and restored in the state the user left off, with very little lag time in between switching. This was something so many were excited about, but at the same time, it absolutely terrified some developers. Before, your application could run in the foreground with the assumption that it was king and when it was pushed into the background it was peon. Prior to iOS multitasking, when your app went away, it was completely shut down. That meant that offensive use of memory wasn’t as obvious because the app didn’t have to share available RAM with others. Let’s just finish this up with saying, now you share resources so it’s much more obvious if you aren’t being as efficient as possible.

When at the Tech Talk in Austin at the end of January, I finally got the gaps filled in on my understanding and use of Instruments. This gave me a plan to find what was going on under the hood and vanquish the problems I ran into.

Instruments

I had been using it before but mostly for finding zombies, overseeing allocations and checking for leaks. As far as those diagnostics were concerned, Visn looked pretty good. After running some other that I learned about, though, that perception changed a bit. With the help of Time Profiler, VM Tracker and Activity Monitor, on top of Allocations/Leaks, I brought my awareness of where the underlying issues were to exactly where I wanted.

Activity Monitor and VM Tracker were the first instruments I ran, naturally, to get an idea what the memory/cpu usage of Visn was like. Although AM is not meant to be an exact representation of what exactly your application absolutely needs to be using at one point, it is a good way to see if it is just going a lot higher than you think it should. This is also where I got that 180 MB number. It wasn’t consistently using that much, but it was always running over 100 at most points. VM Tracker was essential in seeing how much dirty resident memory there was, which for reference is memory that has been allocated and used in the app. I was seeing a trend that it was significantly higher than it should be.

Time Profiler was focused on next and it really helped identify areas that cause the app to jitter or freeze. What it does is tell you how long, in milliseconds, it took to run specific methods. This instrument, along with VM Tracker, tends to be the most misunderstood. They have specific settings that are very helpful in making them much more “human-readable”, especially if your understanding of the underlying foundation is still growing. Typically, here are the best settings to just make sure you have activated for both:

Time Profiler (Check the following to “on” under Call Tree)

  • Separate by Thread
  • Show Obj-C Only
  • Flatten Recursion

VM Tracker

  • On the tool itself, click the information icon. Make sure your style is set to “Dirty, Resident Sizes”
  • While it seems obvious, this tool works like leaks where you need to either snapshot manually or automatically. For more rigorous testing, set automatic. Usually anytime between 3-10 seconds is plenty.

The Findings 

For those that are still making it through this epic, I applaud you. After running all these tests and diagnostics, here’s what I found.

Storing images inefficiently

My logic initially was to parse through feeds and process all images I ran across into what I refer to as a “Feed Collection”. This collection contains Feed Items from all sources that are currently or have been parsed. A Feed Item typically contained a feed url, feed id, image url and a cacheable image data property.

Whenever I was loading imagery, I would both display a version on screen and then store the UIImage I created from incoming data into the associated Feed Item. When, and if, the user decided to go into detail view, I would just display the already stored image. Once the panel that displayed that feed item was gone, I would clear it’s cached image, while still preserving the other properties. This seemed to be efficient, until I learned a bit more about how image data was stored on the device. Despite the compression of an image when it comes from the web or any other source, once it is displayed on screen, it is effectively uncompressed. That means that the actual pixel size was directly related, no matter what, to the memory consumption.

This came as a shock when I found it out but helped me move in another direction. For 2.0.1, I removed the cached object entirely and now fully rely on NSURLRequest with a caching policy of NSURLRequestReturnCacheDataElseLoad. This step alone saved me a ton of memory. Visn was technically using this connection before, which made matters even worse. NSURLRequest was caching the data while the app was then caching the data, in another form, again. What the cache policy on the request does, is it attempts to load data from a url. If that data has already been loaded, the system will pull from its managed cache. If the data has not, it will go through the normal process and give me what I need to display the image.

Changing to this method of storage also allowed for much more graceful handling of memory warnings. Again, I’m not hoping to get any but if I do, it’s good to know that the system is managing the cache of images so, if a memory warning comes around, I know it will be able to bring down usage without defaulting to either an immediate crash or making images disappear randomly.

Not properly cropping/resizing imagery

This was also a big one and is primarily what led to some of the most offensive instances of memory consumption in list view. In my previous post, I mentioned how scaled images negatively impact performance. Well, they also make a dent on memory, as well. In grid view, I was fortunately cropping the imagery correctly, so it was technically optimized from that standpoint. List view was a different story. All images being displayed in that view were being scaled down (instead of resized). The difference between the two is that when you resize an image, you are decreasing its width and height directly, so when you put it in a 325 x 325 slot, the system is drawing an image that is the same dimensions into that spot. When it is scaled, let’s say you have a 1024 x 1024 image going in that same slot. Now the system is not only having to compute each time what it “should” look like in that slot, it is also storing a larger image, which increases memory.

To repair this problem, I made sure all images are resized or cropped, stripped of unnecessary alpha channels and interpolated when necessary.

Not utilizing threads as well as I could

Time Profiler identified many areas that were taking too long in the main thread, which was causing user interaction to be blocked at too many points. I cleared it up by checking all of the methods that were taking the most time to complete. I either made sure they were running on a separate thread or utilizing another route to get a similar result.

This was most prominent when I was actually now resizing then repositioning imagery. When using Core Graphics to resize an image, there’s a certain amount of processing that needs to take place, and that can block user interaction. Making sure that was taking place on a separate thread was essential to maintain a smoother experience. While the iPhone version still has a ways to go in this aspect, iPad is holding up rather nicely.

So, that’s memory

My next and last bit of this segment will focus on how we dealt with existing bugs and interpreting user feedback.

By javier| March 15, 2012

Visn 2.0.1, The Overhaul, Part 1: Performance and Transparency

After releasing 2.0 and bringing Visn to the iPad, I decided it was time to take a step back and make sure that the foundation of the application was good enough to hold up the carefully crafted visuals. I hate to admit it, but things were kind of ugly. Growing pains, it seems, always begin to show up over time on any project you work on. That’s why they need some love on a regular basis. What you did 2-3 months ago might not be quite the best way. Learning a new approach or honing in on some of your weaknesses really brings a light to what you didn’t do well before. It was time for a change and, although it’s not the final end-all-this-is-how-visn-will-always-work-from-now-on kind of thing, it’s a vast improvement.

For those that are curious, here’s some insight as to what exactly was done.

The Foundation

I’m constantly pushing myself to learn more and more about the iOS development platform. Thankfully, I had the opportunity to head over to Austin for the iOS Tech Talk. Along with meeting some of the people at Apple that have made what we do possible, I also gained a lot of insight into how to better utilize the tools they provide. That’s where Visn would gain a huge advantage.

We’ve heard plenty of customers, friends, relatives and animals chirping about the fact that, “hey, this loads kinda slow”. The original underlying structure of the app was built back in March-April 2011 and it didn’t really change much after that. So now, a year later and just 7 months after making the switch to being a dedicated iOS developer, I’ve naturally procured knowledge and experience that didn’t exist before, or wasn’t as mature at least.

“Ok, that’s great, but you still haven’t told us what you did.”

Alright, I tend to ramble, I know. The background info felt necessary so I went for it. Here’s what happened, on a technical level.

Core Graphics and Animation Improvements

So the iOS platform loves to show us beautifully rendered content. What it doesn’t like, however, is a developer that doesn’t fully understand how drawing actually works on the device.

Let me explain.

Our devices are given commands to draw, animate and display content onscreen that are then used to render what the user sees. Depending on the efficiency of these commands, the system might be able to reuse parts of what was drawn before instead of “rebuilding them from scratch” every frame.

Taking a quick step back, a frame is a an individual image. To achieve the illusion of movement, frames are presented to the viewer in quick succession over time. Similarly, the iOS platform likes to be able to present those frames to you as fast as it can (and as quickly as the developer has explicitly requested, in some cases). However, if performance isn’t thought of at all times during development, you put a few barriers in the way of getting an image rendered and thrown to the user. A lot of times, people refer to this as a “slow and unresponsive app”.

Here’s some of the graphics and animation performance issues that impacted Visn:

Transparency

The entire screen of our iOS device is a precious resource. When creating that image, the processor needs to determine what the developer wants to show the user and draw it. If you throw transparent layers, then you get what is referred to as “color blended” content. This means that instead of the processor saying “ok, I’ll draw this one part for this sector” it has to go and draw that, then think about how another layer on top of it affects its appearance, as well as the appearance of that layer, as well as the layer on top of that, and so on. So if you start piling transparent layers and images over everything, you’ll start to see performance degrade over time. The user only gets to see this in the form of “dropped frames”. That means the system just couldn’t keep up, so it dumps frames until it gets to current time. That is bad.

So, I went through the application and identified all areas that were using unnecessary transparency or seeing ways to make seemingly needed transparent areas become more of an illusion of being see-through. This alone really helped speed up interaction but there was a long way to go.

Content Scaling

Another factor that can really slow down Mr. iOS, is scaling content instead of cropping it into a space. You know when you see some imagery that looks really crispy instead of smooth? Go to a website where a portrait of some professional is totally squashed into a space it wasn’t meant to fit into? Make an image your background on your desktop and don’t realize it’s nowhere near the right aspect ratio, so when it stretches out, you are horrified how terrible it looks?

Those are all small examples of what scaling means. When a graphic is created, it takes up valuable memory space and holds onto that chunk of memory until the application is told that it doesn’t need it anymore. Also, to display the graphic, you need to set what is also considered to be a “frame”, not necessarily related to the frame we spoke of earlier, that determines what its position and size are going to be. If the width/height of the graphic don’t match the width/height of the frame/bounds, then it will be scaled in most cases.

This means the processor now has to add an additional pass to rendering that image for us. It will take the image, cache its appearance into memory and then scale it down for each frame. That adds up over time and especially if there are multiple instances of scaled content on screen. Unfortunately, list view was a horrible offender of this and it showed.

What you want to do, is resize/crop the image into what space it will appear so that you can avoid the scaling being done each frame.

That’s it, for now

There was a ton of other lower level work done. The next part will focus on how I reduced the memory footprint of Visn.

By javier| March 4, 2012

Visn 2.0 Now Available


Visn 2.0 is officially available on the App Store. Now you can add your own feeds, share and save your favorite images, and enjoy Visn on both the iPhone and iPad. We’ve had a few wondering. Why 2.0? What’s up with no 1.1? Well, here’s how things went down.

1.1

Since before 1.0 came out, we had a plan for 1.1. Shortly after Visn’s debut on the App Store, we were quite surprised by the overwhelming response. Although a majority was positive, there was some incredibly well thought out feedback that made us really analyze if our initial plan for 1.1 was enough for the healthy collection of users that kept growing by the day. So instead of pushing it out, we took a step back and waited to see what everyone’s initial impressions of the app were, how people used it and, most importantly, what you wanted or expected it to do.

“The Real World” or “Life Gets in the Way”

Once 1.0 was released and the response was clear, our developer, Javier, decided it was time to change his career path. He stepped down from his previous job, deciding to brave the world of freelance as well as devote more time to Futurehaus. He’s now working solely on iOS projects and a much happier developer for it. Although it did kick back our timeline for subsequent releases of Visn initially, what he’s learned so far has only come to benefit what we would eventually call 2.0.

As Javier was starting up his freelance life, our creative team was strapped. JT had just accepted a big promotion at his full-time job and was working on some pretty major projects with serious deadlines and needs. Greg was also working full-time, and so with jobs, wives, girlfriends, and video games, Visn and Futurehaus got temporarily pushed to the backburner. We would still meet and make plans but weren’t able to find the time to bring those plans to life.

Just this past month, Greg also left the full-time “9-to-5(-or-11-and-maybe-weekends)” world. With Javier and Greg finally freed up and comfortable with their flow of incoming projects, and JT finally slowing down a bit at work, our focus came back to Visn.

Yes, 2.0

Back in October, JT and Javier took a majority of the initial feedback and actively reworked the UX and laid out what needed to be done for 1.1. We knew that while there were so many possible ways to enhance and improve Visn, three things were absolutely essential: Custom Feeds, Sharing and, most importantly, Universal.

Then, the three of us sat down over some killer pizza and made a work plan. Visn came back under development. With the help of tools like TestFlight, and the knowledge we’ve gained in the four months since release, we were able to go through revisions and fine tune the new version to a much higher degree of quality than it’s 1.0 counterpart. Once we felt it was ready, we submitted it to Apple.

We are so excited for this release. The enhancements we’ve made and the features we’ve added have turned Visn into a much bigger beast. Simply calling it 1.1 just doesn’t do it justice. No longer are the images confined to the size of your phone — Visn looks great on an iPad and the best part is if you’ve already purchased Visn for your phone, you don’t need to buy it again for your iPad.

Another thing that we know you’ll love is the ability to add your own feeds. A lot of folks commented on the quality selection and variety of content sources in 1.0, and for the most part, we’ve kept and even expanded upon that list. However, we know that we’ll never know about every great image blog out there. More importantly, what we find cool, beautiful, gorgeous and inspirational may not be for everyone — different strokes, right? Now, Visn lets you see what YOU want to see — whatever your fancy, be it maps, cars, sports, or kittens. If there’s a blog with a functioning rss feed, Visn will pull those images and serve them up in both our grid and list views.

When you see an image you like, you can now share it with your friends via Facebook, Twitter, or email. As always you can zoom in on the image and save it to your phone. The image detail view process has been smoothed out a bit, and now you can view the original source in our built-in web browser.

Once you (hopefully) download or update to this new release, we think you’ll agree that this version deserves to be called 2.0.

Visn serves up any images you want to see.
Visn serves up any images you want to see.

What Happens Now

Though we stand behind this release 100%, we still have a lot of big ideas on how to make Visn even better in the future. We’ll try to stay on top of bringing you faster releases — no more waiting five months for an update. Most importantly, we’ll be pulling any logs we get from iTunes Connect on a regular basis and will continue to welcome feedback with open arms. Bug fixes and stability improvements will continually be our top priority. In the end, you’ll see more releases and your Visn experience will only get better. We have so much in store for the future of Visn and we cannot wait to get there to share it with you.

By Futurehaus| December 15, 2011

Jump Complete

Earlier this month, we launched the new Wormhole Coffee website, which includes a blog for them and one for their partner-in-pastry, Fritz. Throughout the process, the Wormhole team remained a dream client — they were responsive, understanding, open to our ideas and basically gave us free reign to “just make it awesome.” As the first client site Futurehaus was involved in, it was a grand experiment that ended up being a ton of fun to work on. Like any project worth its salt, it stirred emotions, brought questions to the table and tested the patience of many. In the end, we learned a lot and came out with a product we’re very happy with. We hope their new site is as fun and eclectic as their shop.

So, go on, have a look.

Post-script: Stay tuned! Phase 2 will introduce the Wormbazaar, an online shop where you can order all sorts of delicious Wormware, including mugs, stickers, shirts, and a few special items designed by yours truly. In the meantime, swing by the Wormhole and pick some up in person. Tell ’em Large Marge sent ya.

By Futurehaus| November 21, 2011

To the Einstein-Rosen Bridge!

The Wormhole Coffee is many things: a) an amazing coffeeshop in Chicago, b) a geek’s paradise, and c) Futurehaus’ preferred off-campus meetup spot and first official client. Not only do they have a huge variety of delicious drinks and edibles, they’ve got a truly massive collection of vintage toys, posters, game consoles and miscellany on display for public consumption.

Wormhole's DeLorean

Fun fact: Futurehaus more or less started in this coffeeshop. We held a bunch of our first meetings and totally loved hanging out there. With their unabashed love of pop-culture, classic sci-fi, and pretty much everything awesome from our childhoods, the Wormhole proved an amazing space for brainstorming and inspiration. We always knew they would be a super fun place to work with. Soon enough, we shot them an email in the hopes that we could help out with their website (they were a very new shop whose digital “face” was a poor representation of who/what they really were). Since those early days, we’ve formed a great relationship with them and have done a handful of projects for them — everything from punchcards to flyers to t-shirts… but alas, no website.

We would have finished the site sooner but we were le tired

Cut to present: We are happy to announce that over the last few weeks/months, we’ve been hard at work behind closed doors starting development on the new Wormhole Coffee website. We’re pretty excited about it — the design and technology is a huge step forward for this little shop and it will hopefully better convey the “essence de worm”. Special shout-outs go to Travis “Praetor” Schaffner at the Wormhole for supporting our vision and letting us go nuts, and to the wonderful Maggie Marlin who lent us her wonderful photo skillz and abilities.

Wormhole Dotcom
Wormhole Blog
Greg Calvert and Javier Otero

Stick around and grab some Mocha Puffs, the show’s going to start soon.

By Futurehaus| September 30, 2011

Futurehaus Blog: Start.

We’d like to share a collection of thoughts, ideas and works in progress with anyone and everyone, so this blog has been brought into being. Let the posts begin!

By Futurehaus| August 24, 2011