Day One: Journaling Made Easy

Day One


Day One is one of those apps.





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

  • Photos
  • Tags
  • Reminders
  • Geolocation data
  • Weather conditions
  • Cloud backup via Dropbox
  • Digital

Day One: journaling made easy.

Understanding Properties in Objective-C and iOS




I’d recommend against thinking you’re better off taking shortcuts by just digging around on 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 (and other sites) become much more meaningful and are very worthwhile.


  • 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
  • Strong reference cycles and how to avoid them
  • Why/How you should “cache” weak variables



iPad Mini vs. Kindle Fire HD


Amazon Kindle Fire HD - Much More for Much Less















Tether iPhone with Verizon






PhoneGap & jQuery Mobile – First Impressions


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.


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


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.”
  • “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.