Day One: Journaling Made Easy

Day One

I don’t buy apps very often. Probably because I can usually find a free alternative that works. However, every now and again the free alternatives are not what I’m looking for and the paid alternatives look fabulously well developed–great UI, great UX–so I take the leap and buy.

Day One is one of those apps.

Probably about a year ago I went ahead and bought it and I’ve never missed the money or regretted it. ($5 really isn’t that much money, it just seems like a lot relative to all those free apps we download. It’s probably cheaper than buying a physical journal!) I’ve always struggled to keep a memoir of my life, but Day One makes it easy because not only are their reminders, but I can take pictures along the way. One of the reasons I don’t write in a journal regularly is because it takes time to describe what I did that day or I’d have to bring the journal with me everywhere I went just to capture a moment in the moment. With Day One, I can capture moments in the moment and all I have to do is take a picture.

While pictures are awesome, words are the essence of any true journal or diary. A photo journal without words is more of a photo album. It can tell a story, but words can add a lot of depth to a picture, much like sound to a motion picture. If typing on the phone sounds ‘no bueno’ to you then just speak into your phone and let it transcribe your voice because Day One supports that too! Brilliant! My greatest entries are probably those that combine pictures with words.

Once again though, writing a long, reflective entry can take time. I’ve found that some times all I need is the time it takes me to get to work on public transit or waiting in the airport for a flight.

Writing in a journal is often more about reflection and meditation than anything. This is one of the keys to relaxation and greater happiness. This is one of the biggest reasons why I write in my journal. Furthermore, I want people to know what my life is about on the day to day, what I think about, what I notice, what’s important to me. I want to go back and remember what I did 10 years ago. I want others to do be able to do that too, if they wish.

In summary these are the reasons why I love Day One:

  • Photos
  • Tags
  • Reminders
  • Varied journal views (i.e. timeline, calendar, photos, year, etc.)
  • Geolocation data
  • Weather conditions
  • Cloud backup via Dropbox
  • Digital

Day One: journaling made easy.

Understanding Properties in Objective-C and iOS

I think one of the first questions all new iOS developers ask is “Why declare properties with attributes like (nonatomic, strong)?” This is especially true for those who learn iOS development through the Stanford Paul Hegarty iOS lectures.

Understanding properties in Objective-C and iOS can be tough the first go around. When I first started programming for iOS I didn’t really understand all the ins and outs of properties and I probably didn’t need to because I wasn’t writing complex applications.

Over the last 8 months I’ve done a fair amount of iOS programming and have run into a number of scenarios where I needed to create read-only properties and thread-safe objects/classes. Some times Stackoverflow.com just doesn’t cut it because there are so many different questions and accepted answers it’s hard to really tell when and why to code what. You always run the risk of just coding something that works, but not really understanding if it’s the best way or not. If you find yourself in this situation–wanting to better understand how to create a property with the right set of attributes (i.e. nonatomic vs atomic, etc.)–then the Programming for Objective-C guide for iOS is the right place to start.

I’d recommend against thinking you’re better off taking shortcuts by just digging around on Stackoverflow.com or random blog posts because reading documentation is boring and goes into unnecessary detail, especially if you want to grasp the fundamentals of when and why to code properties with specific attributes. The official documentation excels in this area because it provides the necessary level of detail with helpful examples. I’ve found it to be much more helpful in understanding the fundamentals of properties in iOS development. However, once you have read the documentation, the topics on Stackoverflow.com (and other sites) become much more meaningful and are very worthwhile.

Instead of paraphrasing the already concise documentation I’ll just summarize some of the key topics you can read about.** If you’ve been coding in Obj-C for a little while already I recommend jumping into the “Data Encapsulation” section of the Programming for Objective-C guide. This section discusses the following concepts:

  • Default property attributes (i.e. readwrite, strong, atomic)
  • When/Why to use property attributes with helpful examples
    • readwrite vs readonly
    • strong vs weak
    • atomic vs nonatomic
    • unsafe_unretained
    • copy
  • When/Why to use variable qualifiers
    • __strong vs __weak
    • __unsafe_unretained
  • Specifying getter and setter names that are different from property names (w/o implementing the method code)
  • Strong reference cycles and how to avoid them
  • Why/How you should “cache” weak variables

If you want further reading on variable qualifiers as it pertains to Automatic Reference Counting (ARC) then I recommend reading the Transitioning to ARC Release Notes. This documentation is quite insightful covers more on variable qualifiers in addition to two examples I found very helpful, namely an example of how the compiler interprets an implicit strong pointer to NSError and an example involving blocks and the __block qualifier.

**This begs the question “Why the blog post then if you aren’t feeding me any new information?” My goal is to provide a point of reference so that I and others will know where to look in the future. It’s not always easy to know where to look when there seems to be endless documentation on all possible subject matter. Furthermore, I’ve summarized the most important topics so I and others know whether that source will contain the information sought.

iPad Mini vs. Kindle Fire HD

I noticed that Amazon.com is taking advantage of a direct product comparison with the iPad Mini. Smart move on their part and good advertising tactic. Go for that swing group!

Amazon Kindle Fire HD - Much More for Much Less

Apparently it’s not iPad Mini vs. Android tablet, but iPad Mini vs. Kindle Fire HD.

Amazon highlights the key characteristics that standout against the iPad Mini: price and pixel density. It even went as far as to be redundant just to drive the point home. Notice the first two points are basically a restatement of pixel density (verbal vs. numerical) and are very similar in argumentative premise. The Kindle Fire also boasts wifi that is 41% faster than the new iPad (purportedly). The quote by Gizmodo adds a nice touch of ethos, though I’m not sure how much validity it really adds.

I stumbled upon an article comparing the new iPad Mini to the Kindle Fire HD. It had some good points. But some of the arguments were bolazo (that’s Uruguayan for nonsensical).

I like Apple products a lot. In general, I think they are well designed. I’ve had a better experience with my MacBook than any other previously owned laptop. Granted your newest product is going to be a better experience than the last (hopefully); however, there are things I just love about my MacBook that I didn’t get with my PCs. I’ve mentioned a lot of them before (trackpad, gestures, Preview, among other things). Of course this is just my preference. Some people hate gestures. I could throw money at them and they would want nothing to do with it, let alone a MacBook.

Back to my point. There are some arguments in the article that are flat out terrible. For example, the author suggests that “[Apple] has gotten away with selling what are essentially commodity products at an extremely high premiums by establishing a strong brand that has embedded in the general population the image of superiority.” The kind of technology Apple sells is not a commodity. This guy is writing like a first-world-ian. The only way in which Apple products are like commodities is that when the price goes up, fanboys and fangirls still buy them. Other than that iPods, iPads, iPhones, MacBooks, etc. are not commodities. Tablets and smart phones in general are not commodities. Ridiculous. On the flip side, Apple has managed to “get away with”, or better said, successfully been able to sell their products at high prices because of the loyal consumer base they have grown as a result of branding, marketing, design and a host of other strategies.

Later the author makes this statement: “In short, while the Apple software ecosystem is closed and very rich today, Android will reach parity and even surpass the richness of the iOS world going forward, eliminating the software ecosystem advantage that Apple can use to justify its higher prices for inferior hardware.” Wow! Google, you should really pay this guy more. …

This is taking me back to my previous rant on journalism a little bit. At this point the author’s persuasive pitch left me unconvinced and I stopped reading. And it’s not because he claims “Android will reach parity and even surpass” iOS. That may very well happen. May the best product “win.” But inferior hardware? Talk about a sweeping generalization of Apple products.

The iPad Mini may not meet the mark of the Kindle Fire HD in pixel density and screen resolution, and I personally think it would have been better to include the Retina display, but to label the rest of the Apple suite as inferior is absurd. Apple is paving the way for higher screen resolution, something that I know has pushed a number of people into the Apple product sphere. Are their products perfect? Obviously not. I think many of us, myself included, have questioned and wondered about some of their strategic decisions. Perhaps I’m focusing on the minor details of his article too much, but he really could have done better in crafting his argument.

I guess my main point is some times I’m a bit struck at the persuasive arguments people conjure up, and yet they fail or choose not to look at the bigger picture. That’s the ugly side of the Internet. We have this glorious tool where people can express themselves. Yet some people, often people who hit the front page of the Internet (Google Search, page 1, in all it’s query-able varieties) just can’t write a well-rounded argument. I suppose they don’t have to and they won’t, especially if they have an agenda (i.e. drive traffic to their site, etc.). What also bugs me is the thought of people accepting their words at face value.

This goes beyond this one insignificant post. It stretches out to articles and media productions on politics, religion, finance, and just about everything else. I hope that people research and investigate for themselves, that they read other articles from different sources, that they work the numbers and check the stats. I think part of the reason I’ve been thinking about this is because I know I’ve fallen into these traps before and I’m sure I write articles that miss important points. Furthermore, a lot of people never care to check the facts and they begin to form solid opinions on topics they know little of other than the fodder that one Internet farmer has fed them.

It’s the same with news on the TV. I can’t stand watching news on TV because of all the political bias and other garbage. And yet I know people who watch the same news station night after night (mostly people from an older generation). Diversification isn’t only an investment principle. I believe it’s enables us to seeing the bigger picture and to develop a more sound understanding of the world around us.

End rant. All in all, I both liked and disliked the way Amazon called out Apple on their front page. It was bold and daring. In a sense, it showed consumers “the truth” about the iPad Mini versus the Kindle Fire HD, albiet biased advertising.

At the same time, I thought the front page comparison was petty. It sorta reminded me of laundry detergent ads, even though in this case it’s more factual. It also reminded me of the Samsung ads. “The next big thing is already here.” This kind of advertising is amusing and can be effective (especially when focusing on the swing group), but there is a higher plane of advertising.

When you have to stoop down to try and show consumers you are better than the competitor by comparing yourself to the competitor’s product, you know you aren’t reaching for that higher plane. Your product should sell itself by showing consumers how it delivers what is most valued and how it fits who they are.

Tether iPhone with Verizon

In case you were unaware as I was, Verizon customers can tether their iPhones without jailbreaking.

Apparently Verizon pressured Google to block apps designed for tethering from Google Play. However, Free Press filed a complaint against Verizon with the FCC. As it turns out, Verizon bought a portion of its cellular band from the government and agreed to a the Open Access Rule. The key is a clause found in the purchase agreement: Verizon “shall not deny, limit, or restrict the ability of their customers to use the devices and applications of their choice on the licensee’s C Block network.” Thus, Verizon settled for some fees and penalties and now all customers can tether for free.

The downside is that Verizon now includes the cost of tethering in their “Share Everything” plans. In other words, you are paying for tethering, you just don’t see it show up on the bill because it’s included in the price. If you aren’t on a Share Everything plan, then I believe you have to pay for the hotspot capability separately. Android users can download apps from Google Play, but as far as I’m aware, Apple is still prohibiting tethering apps from being distributed in the App Store. Regardless, converting your phone into a personal hotspot is possible through Settings.

To enable tethering (aka personal hotpost) navigate to Settings >> General >> Cellular >> Personal Hotspot. Once there, flip the switch to “ON” and you should be good to go. The name of the network will be the name of your phone. For some reason, I couldn’t get my MacBook Pro to recognize my hotspot at first, so I turned the hotspot on and off again and then it recognized it.

You can customize the password and you can tether via wi-fi, bluetooth, or USB. Pretty cool!

PhoneGap & jQuery Mobile – First Impressions

As an intern at Pariveda Solutions, I worked with PhoneGap and jQuery Mobile for the first time. I have to admit, prior to my internship I had heard these terms thrown around a lot but had no idea what they meant. My mind simply translated them to “mobile dev stuff.” After I learned we would be working with them, I did some research with my fellow interns and started to get the picture.

How PhoneGap Broke My Heart

With PhoneGap, I was super pumped about the possibilities of deploying one app to multiple platforms. It seemed like a dream come true for mobile. But nothing is ever that simple. It’s kinda like the phrase “no such thing as a free lunch.” Really, you can get a lunch without paying for it with money, but usually there’s some sort of extra effort involved, time, energy, blah blah blah, thus not so free.

PhoneGap is kinda like that. You think you are going to program one app and deploy to many (if you’re a young, naive programmer like me), but really there’s an extra layer of code you have to program somewhere in between the limited native code and all that JavaScript/HTML/CSS/jQuery to handle the quirks of Android, iOS or whatever platform you deploy to.

That said, I’m not against PhoneGap. The idea of a cross-platform app that can be deployed in multiple app stores is brilliant in my mind. Furthermore, developing these kinds of apps takes a lot less programming language know-how (one language vs. more than one language) and a lot less time to focus on GUI building, which often takes the greatest chunk of time if you develop your app with good UI and UX. Thus, I’m not opposed to PhoneGap. I’m just relating how PhoneGap crushed my dreams because I thought it was going to be easier than that.

But there is a part two to this sad story.

How jQuery Mobile Broke My Heart

So after I finished researching PhoneGap, I launch Xcode, start my PhoneGap project and dig into the code to see what’s going on, to figure out how PhoneGap does its magic. That takes a while. For those of you who are unfamiliar with PhoneGap and how it works, it basically displays a web view without the search bar and toolbar to display a web page. It also (of course) has to translate both ways between native code and JavaScript. You code the app using HTML, CSS and JavaScript. So I figure that out and start planning how I’m going to code my app.

I want my app to look like a real iPhone app. I also want it to look like a real Android app. Or at least I want both users feel like they are using a native app. That’s when I realize, I can’t accomplish this goal, or at least not entirely. It’s hard to fool an experienced iOS or Android user that they are using a native app. They know what the buttons look like, how the generic user experience goes, what the generic color schemes are, etc. Furthermore, I’m not going to accomplish the native experience by just coding basic HTML and CSS. So that’s when, as a developer, you turn to solutions like jQuery Mobile and Sencha Touch.

So I read up on jQuery Mobile and start coding it into my app. Everything works great and it looks awesome. I’m stoked because jQuery Mobile is making my web view look like a native app.

Then I get past the basics and I start coding in lists. And I want them to load content dynamically. I also want to transition from one list to another list. I want the lists to be scrollable. Then I want to include an input field on a page that is scrollable. Etc. etc. This all works in jQuery Mobile. It’s awesome. I’m pretty impressed at all the features jQM has to offer.

At the same time though, I can’t get past the feeling that all the jQ coding, jQM coding and HTML attributes sorta feels like a hack. Plus it’s hard to replicate native code when with something that’s not native. jQM does a great job at recreating the native experience, but transitions between pages aren’t as smooth always. jQM has bugs that need to be worked out for certain features. It’s a product in development and it’s new, so it’s bound to have a few weak points.

Key Takeaways for Me

PhoneGap and jQuery Mobile are powerful tools to use for cross-platform mobile development. They offer a lot of features to make cross-platform apps look native. They are not the same experience though, so don’t get any similar preconceived notions. They have their place and there are reasons why you’d want to use them.

jQuery Mobile in my experience can be slow and appear glitchy as you transition between pages and when pages render dynamically. Rendering HTML UI content is inherently different from rendering native UI content. Many of the UI “flaws” are imperceptible on a desktop or laptop due to faster hardware. However, these differences truly can affect the user’s experience. With time, I think many (not all) of these issues will go away. jQuery Mobile will be optimized, mobile hardware will be faster and so on.

For those of you who are experts on jQuery Mobile, I’m sure you could teach me a thing or two. I’d love to learn.

Forgotten Xcode Debugger Tricks

If you’re a pro iOS programmer, you may be a master at using the debugger. I, however, am not quite there yet.

I recently realized I’m very inefficient at debugging. So I decided to revisit Paul Hegarty’s lecture on the debugging. I’m glad I did because I relearned a couple tricks I had forgotten about debugging in Xcode.

Trick #1 – Immediately Break On All Thrown Exceptions

Instead of having all your uncaught exceptions get tossed up the stack to main, tell the debugger to break once they are thrown. This will help you debug your code much faster since you will know right where the exceptions are thrown in your code. To set this up, do the following:

  1. Go to the Breakpoint navigator in Navigators pane on the left (Cmd + 6)
  2. Click the little plus sign (+) button at the very bottom left
  3. Select “Add Exception Breakpoint…”
  4. Keep the defaults and click “Done”.
Xcode Debugger Break On All Exceptions

Trick #2 – Conditional Breakpoints

This is awesome for those methods that get called over and over again and you want to set a breakpoint to check the value of some variable (e.g. make sure it’s not equal to 0 or nil) but you don’t want your app to break…every…single…time. To enable conditional breakpoints follow these steps:

  1. Set a breakpoint
  2. Right click (or two finger tap) over the breakpoint
  3. Select “Edit breakpoint”
  4. Enter in a value (e.g. result == 0)
Xcode Debugger Conditional Breakpoint

Trick #3 – Access Variables Using the Debugger CLI

Sometimes it’s nice to see the value of a variable without hovering over it. From the debugger console, you can type something like print [self myVariable] to see the value of myVariable. However, this only shows the most information, like the value of the pointer (which if it’s 0x0 then it’s nil).

Another alternative is to do something like po [self myVariable], which basically calls the description method on the the object so it will print it’s description (“po” stands for “print object”). If myVariable is an array, you will see the contents of the array. This becomes quite useful if you get into the habit of coding description methods for your classes because then you can enter po self in the debugger and get all the information you need on the current instance of your class.

Conclusion

As you can imagine, there are a lot of other useful things you can do with simple modifications of these three tricks (i.e. adding actions to tricks 1 & 2, ignoring breaks on trick 2, exploring the other commands that can be used in the debugger CLI, etc.).

Lesson learned: Don’t be inefficient with your debugging. Explore the available tools.

Lithium-ion Longevity: Prolong your battery’s life

Preface

I remember my first laptop pretty distinctly. I got it for Christmas/birthday roughly 9 years ago. I remember it mostly because it was a the perfect example of a hardware design disaster. It suffered from “heat exhaustion” so badly I shipped it to the manufacture 3 times and each time they found nothing wrong with it. Of course every time I called tech support, they had me take out the RAM and the harddrive and put them back in and make sure the BIOS was up-to-date. Then, finally, I got them to replace the motherboard and I think even the entire computer replaced again later. But to no avail, the new hardware had the same problem. A total catastrophe in heat management. Thank goodness they discontinued its production within a few months I think.

However, more to the point of my story, I also remember this was the first time I learned about how to get the most life out of a rechargeable battery. I can’t tell you what kind of battery it was, I just distinctly remember being told to charge the battery 100% and then run the computer until it died at 0%.

Since that day, I’ve tried to do the same thing for most of my rechargeable electronics. However, more recently, I’ve kinda started to give up on the idea. I never did it with my iPad 2 nor my iPhone 4 either (I think). I started getting this feeling it did nothing for my battery.

I recently discussed the whole “charge-and-kill” concept with two friends, one of which just bought a new iPad 2 and another an electrical engineer. The one who bought the iPad 2 was talking about how he hadn’t charged his device for a couple days and didn’t plan to until the battery died to increase its longevity. I told him I didn’t really think that did much to modern batteries. I told him what my uncle (also an electrical engineer) told me, that it really only applied to “old” batteries and that the new ones didn’t need to be fully discharged during the first use. The electrical engineer immediately chimed in that it still applied to Lithium-ion (Li-ion) batteries and gave me his reasons. I didn’t argue with him because I wasn’t sure. Afterall, I’m only a systems guy, not a hardware guru.

After that discussion, I decided to do some research and get the facts on extending battery life in our modern electronics. Along the way I’ve encountered more people who fully discharge their devices in hopes of prolonging battery cycle life. I hope this post will be of use to all who adhere to this dated philosophy.

NiCd: Debunking the Modern Myth

First, let’s talk about what I’ve dubbed the “charge-and-kill” myth. Where did this concept originate and is it really a myth?

Older rechargeable electronics typically run on Nickel-Cadmium (NiCd) batteries. These batteries require a process Battery University refers to as priming. Priming is…:

…a conditioning cycle that is applied as a service tool to improve battery performance during usage or after prolonged storage. Priming relates mainly to nickel-based batteries….Manufacturers advise to trickle charge a nickel-based battery for 16 to 24 hours when new and after a long storage. This allows the cells to adjust to each other and bring them to an equal charge level. A slow charge also helps to redistribute the electrolyte to eliminate dry spots on the separator that might have developed by gravitation.

Battery University also discusses the process of formatting. Some batteries, like NiCd and lead acid-based batteries, are formatted through continued use. Formatting…:

completes the manufacturing process and occurs naturally during early usage when the battery is being cycled….Nickel-based batteries are not always fully formatted when they leave the factory. Applying several charge/discharge cycles through normal use or with a battery analyzer completes the formatting process.

Furthermore, NiCd batteries are known to develop a kind of “charge memory” over time. In other words, if you never fully charge and discharge the battery, it will only remember the basic range of charge it holds. For example, if you always keep your battery charged between 50-100%, it will start to remember this charge range and lose its ability to hold the original 0-100% range. This memory effect occurs from a lack of use of the materials in the battery, which actually begin to lose their battery-like, charge holding characteristics.

This is why so many people talk about completing a full charge/discharge cycle with electronics. Thus the “charge-and-kill” method applies to NiCd batteries; however, it does NOT apply to Li-ion batteries.

The Truth About Li-ion Batteries

Li-ion batteries do NOT suffer from the memory effect mentioned above. Li-ion batteries do not require priming or formatting. To quote Battery University again:

Lithium-ion is a very clean system and does not need formatting when new, nor does it require the level of maintenance that nickel-based batteries do. The first charge is no different than the fifth or the 50th. Formatting makes little difference because the maximum capacity is available right from the beginning.

Battery Univeristy goes on to describe what some people attribute to a pseudo-memory effect being corrected in a Li-ion:

Nor does a full discharge improve the capacity once faded. In most cases, a low capacity signals the end of life. A discharge/charge may be beneficial for calibrating a “smart” battery, but this service only addresses the digital part of the pack and does nothing to improve the electrochemical battery. Instructions to charge a new battery for eight hours are seen as “old school” from the nickel battery days.

Which begs the question: How do you prolong the life of your Li-ion battery?

Five Ways to Prolong Li-ion Battery Life

I will discuss 5 of the best ways to get the most out of your Li-ion rechargeable battery. Battery University has an extensive article on the why’s.

  1. AVOID HEAT. Heat is bad new bears for just about all electronics. It’s also true for your battery; keep it cool. For laptops, avoid surfaces that will inhibit cooling or block fans (e.g. blankets, pillows and all sorts of fluffy, soft things). Even better, use a laptop stand. Lifehacker has a lot of cool, cheap ($8) DIY laptop stands. If you are super cautious, use a cooling pad. If your phone is really toasty, read this.
  2. UNPLUG WHEN FULLY CHARGED. Don’t keep your device plugged in perpetually after it has reached a full charge. If you want to leave it plugged in overnight, get something like a Belkin Conserve Socket.
  3. DISCHARGE MODERATELY. Don’t discharge your battery to a shallow 90% all the time and then plug it in again. Conversely, don’t discharge your battery to a deep 0% or 10% routinely. Just keep it moderate around 50% or so. This yields an optimal cycles-to-usage ratio (see Battery University for a table).
  4. OBEY THE 40-80% RULE. Charging above 80% produces excess of heat. Charging longer (because you let your battery level drop so low) produces more heat.
  5. DEEP DISCHARGE ONCE A MONTH (OR SO). While this will not prolong the life of your Li-ion battery, it will keep the battery “smart.” In other words, it will more accurately report how much life is remaining.

Update: 1/16/2014

Based on user comment below, I have re-read the Battery University article referenced and have reevaluated some of my recommendations above. Instead of changing my recommendations or re-wording them, I would like to quote some of the more important lines from the Battery University article and you can make your own inferences.

  • “…the worst situation is keeping a fully charged battery at elevated temperatures…”
  • “A partial discharge reduces stress and prolongs battery life. Elevated temperature and high currents also affect cycle life.”
  • “Higher charge voltages boost capacity but lowers cycle life and compromises safety.”
  • “For long-term storage, manufacturers recommend a 40 percent charge. This allows for some self-discharge while still retaining sufficient charge to keep the protection circuit active.”
  • “Batteries are also exposed to elevated temperature when charging on wireless chargers. The energy transfer from a charging mat to a portable device is 70 to 80 percent and the remaining 20 to 30 percent is lost mostly in heat that is transferred to the battery through the mat.”
  • ‘Should I disconnect my laptop from the power grid when not in use?’ many ask. Under normal circumstances this should not be necessary because once the lithium-ion battery is full the charger discontinues charge and only engages when the battery voltage drops. Most users do not remove the AC power and I like to believe that this practice is safe.”

My apologies for any misinformation and my thanks to the comments.