I’ve always been a fan of PHP’s type comparison tables, and today Aaron and I started talking about how you can write the following in objective-c, but not in java:

if ( myObject )

I started wonderring how this works. Is [myObject description] getting called behind the scenes here? (Spoiler: The answer is no.)

I built a quick project to figure out why this happens, and some of my results were surprising. Essentially, you should never write if ( myObject ), because it is probably not what you want. It’s basically always true unless you initialize your objects to nil. (I actually recall that auto-initialization of objects to nil was one of the new language features announced last week at WWDC.)

Here are my findings for the statement: if ( X )

I learned something. I hope Aaron did too.

Disclaimer: I do not generally read programming books from start to finish! Instead, I read them much as I would read a blog that I’ve discovered for the first time, skimming the archives (table of contents), and then taking-in the first few sentences of parts that look interesting to me, and bookmarking posts that I want to read in greater depth (dog-earing pages that deserve a second glance). I almost never go back for those second glances, so basically I have a bunch of programming books laying about that look like they’ve been heavily read, when in fact they’ve hardly been cracked. My excuse is that programming books are so seldom relevant past their publish date that keeping them for reference seems silly. If I’m paging through a book’s contents in search of some solution, it usually means I just don’t know the right search terms. When I find some pages that seem relevant, I then turn to the web with my newfound knowledge, and feel vindicated when I find some piece of web-content that appears (at least at first glance) to be superior and more timely.

I do still tend to keep those books around, however, mostly so I can look through their code examples. I find books that consist of mostly code are almost always more interesting than those that try and teach you some general topic. You can usually find nice code examples on the web, of course, but they are seldom explained in as much detail as you would find in one of these “by example” books. In this case, I have in front of me two books that both attempt to teach some topic, but do so with heavy use of examples. They are hybrids, if you will, of books that teach a general topic, and books that consist of mostly code examples. Maybe all programming books exist on a spectrum with pure thought and abstract theory at one end, and pure code (and more easily out-of-date examples) on the other.

The first of these is Professional iPhone and iPad Database Application Programming, by Patrick Alessi, published by Wiley (Wrox) in 2011. With chapter titles like “Introducing Data-Driven Applications”, “The iPhone and iPad Database: SQLite”, “Displaying Your Data: The UITableView”, and “iPad Interface Elements”, you would definitely not know at first glance that this is an example-driven book. In fact, each of those sections (and all the other sections of the book) run you through the creation of a sample project, each building on knowledge gleaned in the previous chapters. The first chapter includes a very nice introduction to Xcode and shows you how to create a simple UITableView based application.

The following chapter, “The iPhone and iPad Database: SQLite”, goes a bit farther down the UITableView rabbit hole with its sample project, and introduces SQLite besides. This chapter definitely endeared me to the author when it said: “While Core Data is the recommended framework for creating data on the iPhone, you may want to forego Core Data and use the SQLite API directly for several reasons.” The author then lists several compelling reasons! This may be a heretical position to take, but avoiding Core Data has always been my preference, although I do occasionally wonder if there are ever good reasons to use Core Data of which I am simply ignorant.

The author does later dedicate five chapters (about a third of the book) to using Core Data, so he can’t think it’s entirely useless. He does not, IMHO, (at least in the cursory skimming I gave that portion of the book), provide any compelling reasons to use Core Data. The closest he comes is when he says (repeatedly) that using the graphical data modeling tool will dramatically speed up the development time of your data driven app. I fail to see how this is the case! If creating your db schema is taking up a lot of your development time, I think you’re probably doing something wrong, or possibly you just aren’t familiar with SQL in general.

(A decent db abstraction layer to handle your SELECT, INSERT, UPDATE etc. calls is also a must, and I am disappointed to report that Alessi’s book does not cover this topic. There is at least one decent open source wrapper available (called FMDB), although there are things I would change about it — namely the API for retrieving your result sets.)

Unfortunately, the portions of the book dedicated to the Core Data modeling tool fall into the “already obsolete” category of coding examples, because they do not appear to cover the Xcode 4 interface. I created a sample project using Core Data to look at the modeling tool, and like Interface Builder, it has been consumed by the “one window” paradigm prevalent in all things Xcode 4. Reading the first couple of chapters on Core Data will probably give you the base knowledge needed to use it anyway, but as I said earlier, google can probably do a better job.

The last third of the book consists of a couple of chapters about integration with web services. This topic makes a lot of sense to include in a book about data-driven applications, but it’s definitely given less attention than the previous two sections. I really think the book should have been expanded quite a bit, both to go into more detail about the stuff it does cover, and also to cover additional stuff that was notably absent. Off the top of my head, here are headings I would have liked to see: best practices for storing data retrieved from web services, how to deal with syncing issues, common tools for consuming web services, and at least one code example for parsing and consuming JSON. Unfortunately, JSON is given only a cursory mention, and its superiority to XML for the task at hand is not, as I feel it it should have been, firmly established.

In the beginning of chapter 10, “Working with XML on the iPhone”, there is a section called Synchronous Data Retrieval, in which some lip service is given to NSString‘s stringWithContentsOfURL: selector blocking your UI, but then it is not made clear that the subsequent code examples (using NSURL and NSURLRequest) are asynchronous in nature! Also, on the topic of “common tools”, the book pretty much writes everything from scratch in this section. I can understand the impulse that the author may have had to explain all the gory details of xml parsing and NSURLRequests without complicating matters by introducing open source libraries that simplify these processes, but they save far more time than I’m liable to believe you can save by using Core Data. If you are consuming web services from your app, you would be stupid not to use (or at least look at) ASIHTTPRequest. That little project has probably saved me dozens of hours in the last three months. On the subject of XML parsing, the question is not whether you should use an external parser, but rather which XML parser is right for your needs!

Overall, I didn’t expect to read as much of Professional iPhone and iPad Database Application Programming in detail as I ended up reading for this review. I don’t know how much of that was due to wanting to give it a fair read in spite of my bias against using Core Data, and how much was due to the author’s really well written prose. Database applications is about as dry a subject as they come, and yet I never felt lulled to sleep in the way that many programming books have a tendency to do to me. If you are not familiar with SQLite, or programming for UITableView, I would definitely highly recommend the first four chapters of the book. As for whether they are worth the asking price, (currently $30 on amazon), I’ll leave that up to you.

Unfortunately, I think I’m going to have to leave any in-depth review of my second learn-by-example iOS book for another day: Learning iOS Game Programming: A Hands-On Guide to Building your First iPhone Game, by Michael Daley, published by Addison Wesley in 2011. This book takes you through the author’s process of building an iOS game from start to finish. The game you build, Sir Lamorak’s Quest, is available as a free download from the app store, so you could potentially download it and see if it’s got stuff in it you’d like to know about. I haven’t actually looked at the game for more than a minute or two, but I know from personal experience that parsing through the source code of a game, even one I have no interest in ever making, is always fascinating to me, so I’m quite excited to dig into this book.

Cross-posted on Martin’s dev blog, Chesstris.

From the android-pulltorefresh repo, https://github.com/johannilsson/android-pulltorefresh

“Pull To Refresh” is a UI gesture made popular by the Twitter for Iphone app. It allows a user to refresh a list by pulling down and releasing from the top of the list. IOS developers have had library support for this feature for some time now. Over in Android-land, only the official Twitter app has managed to implement this gesture. Long-promised to be open-sourced, Twitter’s solution is still secret and Android developers have no official means to implement this increasingly demanded feature.

But thanks to Android’s open eco-system, we can build this into our Android app’s using the open-source android-pulltorefresh library developed by Johan Nilson. With thanks to the projects other contributors, his library is capable of producing a UI experience similar to the Twitter app, with support all the way back to 1.5.

The project provides a simple and sufficient example app to demonstrate the library use, but I needed something a bit more robust when I was implementing this in my application. So I thought I’d share my changes here, applying it to example application provided in the project.

Let’s start with a brief explanation of how this works. The android-pulltorefresh library provides a custom ListView that includes a special header. The list is initially displayed with the first item selected. This hides the header from view. The custom ListView responds to touch events so that when you pull down on the list, the header is displayed and handles displaying “pull” and “release” text and animation based on how far you are pulling down. Once its released, the header remains visible with the “loading” message until the view is told the refresh is complete, then it resets the header so its hidden once again.

Getting the basic functionality implemented is straight-forward. First, setup your layout and reference the custom ListView.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >
    <!--
    The PullToRefreshListView replaces a standard ListView widget.
    -->
    <com.markupartist.android.widget.PullToRefreshListView
        android:id="@+id/android:list"
        android:layout_height="fill_parent"
        android:layout_width="fill_parent"
        />
</LinearLayout>

Now in your ListActivity you need to do 2 things, respond to the refresh request and let the view know when you’re done.
To handle the refresh action the custom view notifies an OnRefreshListener that you can implement to handle your refresh operation.
In the code below you’ll see that it implements the onRefresh method of the listener and wisely executes the refresh on a background thread using an AsyncTask.

 
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.pull_to_refresh);
 
        // Set a listener to be invoked when the list should be refreshed.
        ((PullToRefreshListView) getListView()).setOnRefreshListener(new OnRefreshListener() {
            @Override
            public void onRefresh() {
                // Do work to refresh the list here.
                new GetDataTask().execute();
            }
        });
        ....

Once your refresh is complete, notify the view by calling its onRefreshComplete() method. In this example, we call this method on the UI thread once the task is completed.

private class GetDataTask extends AsyncTask {
 
        @Override
        protected Void doInBackground(Void... params) {
            // Simulates a background job.
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                ;
            }
            return null;
        }
 
        @Override
        protected void onPostExecute() {
            mListItems.addFirst("Added after refresh...");
 
            // Call onRefreshComplete when the list has been refreshed.
            ((PullToRefreshListView) getListView()).onRefreshComplete();
 
            super.onPostExecute();
        }
    }

So that’s basically how the example app from the project is setup. It just initializes a list of Strings and then on every refresh adds a String to the beginning of the list. In a real application we’ll probably need to beef this up a bit.

First let’s take that Task to task and do some real work. In my situation I need to refresh the list by calling an external api and retrieving all the data to be displayed. In this case its actually more efficient just to rebuild the whole list rather than calculating deltas and prepending to the existing list. For this example, assume we have a List as a class-level field managed by a custom ArrayAdapter.
Here’s the first iteration, the list is re-initialized in the task’s onPreExecute() phase, and the work is moved into the doInBackground() method.

private class GetDataTask extends AsyncTask {
 
        @Override
        protected void onPreExecute() {
		mList = new ArrayList();
	}    
 
        @Override
        protected Void doInBackground(Void... params) {
            JSONArray results = api.getData();
            for (int i=0; i < results.length(); i++) {
                ListData data = parseResult(results[i]);
                mList.add(data);
            }
            return null;
        }
 
        @Override
        protected void onPostExecute() {
            // Call onRefreshComplete when the list has been refreshed.
            ((PullToRefreshListView) getListView()).onRefreshComplete();
 
            super.onPostExecute();
        }
    }

Seems like that should work ok, but I ran into a problem with this approach. As the user pulls down on the list, the onRefresh() method is called triggering the task, which starts by clearing out the mList array. At the same time, it seems that because of the UI changes, the system appears to be taking some measurements which is causing the getView() method to be called on the adapter that is managing the list. Now because we’ve emptied out the list, the application can exhibit some unpredictable behavior.
Let’s solve this in the next iteration by loading a temporary list in the background, and switching the list once we’re done. We should also consider that its possible we have some error while retrieving the new data, so in that case let’s not refresh the existing list. At least the user will still see their existing data.
Ok, now the GetDataTask looks like this:

private class GetDataTask extends AsyncTask {
 
        private List localList;
 
        @Override
        protected void onPreExecute() {
	    localList = new ArrayList();
        }    
 
        @Override
        protected Void doInBackground(Void... params) {
 
            try{
                JSONArray results = api.getData();
                for (int i=0; i < results.length(); i++) {
                    ListData data = parseResult(results[i]);
                    localList.add(data);
                }
            } catch (Exception ex){
                localList=null;
                Log.e(TAG,"Exception during refresh:",ex);
            }
            return null;
        }
 
        @Override
        protected void onPostExecute() {
 
             if(localList != null && !localList.empty()){
                 mList = localList;
                 mListAdapter.notifyDataSetChanged();
             }
            // Call onRefreshComplete when the list has been refreshed.
            ((PullToRefreshListView) getListView()).onRefreshComplete();
 
            super.onPostExecute();
        }
    }

Alright, that’s looking pretty good now. For completeness we really should handle the possibility of the task getting cancelled. This can happen when the user navigates away from the app and the task is killed before its completed. This will cause the onPostExecute() method to not be called and so the onRefreshComplete() method won’t be called. Depending on how the user navigates through the app, they could return to this activity without going through the complete onCreate() lifecycle, and you’ll end up with the screen still showing the “loading” progress message in the header. This is common when using tabs between multiple ListViews.
Also, the documented best practices for implementing an AsyncTask says that in long running background work you should periodically check if the task has been cancelled and try to gracefully quit your work and exit. So let’s get all of that in there.

private class GetDataTask extends AsyncTask {
 
        private List localList;
 
        @Override
        protected void onPreExecute() {
	    localList = new ArrayList();
        }    
 
        @Override
        protected Void doInBackground(Void... params) {
 
            try{
                JSONArray results = api.getData();
 
                // check if task was cancelled during long api call
                if(isCancelled(){
                  return null;
               }
                for (int i=0; i < results.length(); i++) {
                    ListData data = parseResult(results[i]);
                    localList.add(data);
                }
            } catch (Exception ex){
                localList=null;
                Log.e(TAG,"Exception during refresh:",ex);
            }
            return null;
        }
 
        @Override
        protected void onPostExecute() {
 
             if(localList != null && !localList.empty()){
                 mList = localList;
                 mListAdapter.notifyDataSetChanged();
             }
            // Call onRefreshComplete when the list has been refreshed.
            ((PullToRefreshListView) getListView()).onRefreshComplete();
 
            super.onPostExecute();
        }
 
        @Override
        protected void onCancelled() {
             // reset the UI
             ((PullToRefreshListView) getListView()).onRefreshComplete();
        }
    }

Now that you have a solid refresh implementation you may want to tweak the design of the refresh header. In the sample application they are using the Android “Light” theme. This makes the text black and easy to read. But if you’re using the default “Dark” theme you’ll find the text very hard to see. Here’s a look at the text portion of the refresh header layout, you can see that it references an attribute for the textAppearance style.

        <TextView
            android:id="@+id/pull_to_refresh_text"
            android:text="@string/pull_to_refresh_tap_label"
            android:textAppearance="?android:attr/textAppearanceMedium"
            android:textStyle="bold"
            android:paddingTop="5dip"
            android:layout_width="fill_parent"
            android:layout_height="wrap_content"
            android:layout_gravity="center"
            android:gravity="center"
        />

Let’s tweak the color of the text to make it readable in our application. To do that, we’ll create a theme that overrides the style used by the textAppearanceMedium attribute. We’ll override this with our own style, which will inherit from the Android TextAppearance.Medium style and override the textColor attribute. Got all that?

First, here’s what Android’s style declaration looks like:

<style name="TextAppearance.Medium">
        <item name="android:textSize">18sp</item>
        <item name="android:textStyle">normal</item>
        <item name="android:textColor">?textColorPrimary</item>
</style>

Now here’s our theme and style declaration:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="MyCustomTheme" parent="android:Theme.NoTitleBar.Fullscreen">
    	<item name="android:textAppearanceMedium">@style/TextAppearance.Medium</item>
    </style>
 
    <style name="TextAppearance.Medium" parent="android:TextAppearance.Medium">
    	<item name="android:textColor">#FFCDC9C9</item>
    </style>
</resources>

And finally edit the Android Manifest in order to use the new theme:

<application android:name="MyApplication"
                     android:icon="@drawable/icon"
                     android:label="@string/app_name"
                     android:theme="@style/MyCustomTheme">
</application>

And that’s it, everything you you need to implement the pull to refresh gesture, handle the operation and customize the UI.

By the way, the android-pulltorefresh library is made available under the Apache License, V2.0. So you need to maintain any NOTICE files and copyright headers from the source. But you are free to redistribute in derivative works for commercial use.

Originally posted on Shared State

Just about a week ago I picked up a hot (no pun intended*) new device from my Verizon Wireless contact.  It’s the Samsung 4G LTE Mobile Hotspot.  Or as I like to call it: The SCH–LC11.  Not really.  We’ll stick with ’4G Hotspot’.  This is one of two 4G LTE hotspots now available on Verizon Wireless.

If you’re not familiar with what a ‘mobile hotspot’ is, allow me to give you a quick lesson.  Basically, a mobile hotspot works like the wireless internet in your house.  A data connection comes in and a WiFi connection is spit out.  However, instead of being connected to a cable modem, the data connection is a cellular connection.  The WiFi part works pretty much the same.  The big difference is that you can only connect up to 5 WiFi devices, BUT you can connect ANY WiFi device; Laptops, iPads, mobile phones, game consoles.  Also, it wouldn’t be very ‘mobile’ if it weren’t battery powered.  Sometimes these devices are called MiFi.

Mobile hotspots have been around for a couple of years now.  The latest incarnations now pack 4G technology.  This Samsung hotspot is rocking Verizon’s 4G LTE, but it’s also compatible with their 3G towers.  This gives you awesome coverage in and out of 4G service area.  The first night that I had the device, I was in St Cloud, MN.  St Cloud is not a 4G city, but I was able to connect the company iPad to Verizon’s 3G network and check email, update some apps, and test one of our client’s apps.  During my trip back to the Cities I was able to stream a comedy special on Netflix.  All 3G.  All the way. In fact, even when I reentered 4G airspace, it didn’t automatically switch over.  Once I turned it off and back on, it was on 4G just fine.

During the work week, I had a mission:  Use the 4G hotspot for an ENTIRE day of work.  Mission successful.  I did this for two days, last week.  For the purpose of testing the connection, and not the battery, I had the hotspot plugged into an outlet.  As you can see from the test results below, the 4G data connection is just as fast as our office connection.  Granted, there are 10 other people using our office connection.  There were some random service interruptions.  All I had to do was reset the modem and continue on.  I came back from lunch one day and had a mini freak out because I couldn’t connect.  What I didn’t realize was that the hotspot shut itself off to conserve power.  All I had to do is boot it up, and connect again.

Office Connection

Verizon 4G LTE Connection

This particular hotspot is very compact.  It’s about the size of a deck of cards, only thinner.  All of the surfaces are soft-touch, so it doesn’t slide around if you use it in the car.  There is a single micro USB port on the side and a single power button on the face.  Your connection status is indicated with 3 LEDs, also on the face; One for 4G, one for 3G, and one for WiFi.  I wish there was a small LCD display to give you more feedback about your connection and battery.  The LEDs only indicate that you have a 3G or 4G connection; not the signal strength.  Also, there is no way to see how much battery you have left.  Although, I have seen the LEDs turn different colors.  Maybe there’s a decoder ring that can help identify what they mean.  The power button also has an LED.  Under the battery cover there is a reset button and the 1500 mAh battery.

The Samsung 4g LTE hotspot is available now from Verizon Wireless or Best Buy for $99.99 (new contract and what-not).  If you want to spend a little less, you can pick it up from Amazon Wireless for $19.99.  There are two plans available:  5GB for $50/mo and 10GB for $80/mo.

All-in-all the Samsung 4g LTE hotspot is a great mobile hotspot.  It’s small. It packs Verizon’s 4G LTE technology.  It’s relatively inexpensive.  I would like to have some more indicators for signal strength and battery.  With many new mobile phones coming with some sort of hotspot/tethering option included, this device may not be for everyone.  But if you want to maybe save some money on your monthly internet connection, you can get a hotspot, use it at home, and then take it with you when you’re out and about.

*pun totally intended

On a chilly April Saturday, the American Swedish Institue broke ground for the Nelson Cultural Center, a modern addition to ASI’s existing Turnblad Mansion.  The new center is a state of the art building, with a 325 seat event space , craft workshop, conference room, retail shop and an additional gallery.  The lower level offers more space for collection storage, exhibit prep and a utility tunnel that connects the new building to the Turnblad Mansion.  The Nelson Cultural Center is tracking to be LEED Gold certified, and will achieve this by using sustainable materials, geothermal heating and cooling systems, a green roof, and water conservation strategies.  The Turnblad Mansion will also receive updates as well.  The lower level will be renovated to offer additional storage for Swan Turnblad’s archive.  There will also be new classrooms and a community hall, with kitchen facilities.

Recursive Awesome partnered with Adolfson & Peterson Construction — the general contractors for the project — to develop an iPad app, which allows ASI members, volunteers, and visitors alike to take a virtual tour through new Nelson Cultural Center and Turnblad Mansion renovations.  Not only can you keep up to date with the latest project news, you can learn more about the American Swedish Institute in the ‘ASI Is…’ section.  You can read about the sustainable aspects of the project, and understand what it means to be LEED Gold certified.  There is a ‘Virtual Tour’ that lets you learn more about key areas of the project, just by tapping on the map.  Lastly, you can give & get involved yourself!  The app offers the opportunity to donate, join as a member, volunteer, or sign up for ASI’s Klipp! newsletter.

Kevin Lind (Virtual Construction Manager, A&P) was present at the groundbreaking — and helped visitors use  the app — said “My biggest reflection on the day was the linking of generations. Seeing families sit down together and walk through the app, asking question of each other”.  He went on to say “We had numerous people spend 30 plus minutes sit down and thumb through the content that is good to see.  My favorite part is the virtual tour — Google style maps — but really makes a huge leep in the direction of a new way to view your project”.

The app will be on display in the solarium of the Turnblad Mansion, during construction of the Nelson Cultural Center.  The app also includes a ‘kiosk’ mode — accessible from the iOS settings menu — which will allow every guest to have the same experience.  It will be available in the Apple App Store, for everyone to download and stay up-to-date with the project.

About The American Swedish Institute

The American Swedish Institute, founded in 1929, serves as a gathering place for people to share stories and experiences around universal themes of tradition, migration, craft and the arts, all informed by enduring ties to Sweden.
http://www.americanswedishinst.org/

About Adolfoson & Peterson Construction

A&P is one of the top 50 construction companies in the U.S., providing construction management, design/build and general contracting services to public and private clients. A&P serves the K-12 school, energy, healthcare, higher education, municipal, multi-family, retail, and senior living market segments from its offices in Arizona, Colorado, Minnesota, North Carolina, Texas and Washington.
http://www.a-p.com/

About Recursive Awesome

At Recursive Awesome we focus on the design, development, and support of tablet, mobile and web applications. We use Agile software development practices, to create RESTful API’s (Ruby on Rails), as well as mobile (iOS, Android, Blackberry and Windows Phone 7) and web products for ourselves and our clients.
http://www.recursiveawesome.com/

Media Inquiries:

Breon Nagy
Recursive Awesome
breon@recursiveawesome.com
612.399.6626