Pronoid Android

This blog has moved

2010-04-16T07:14:00.001-07:00

This blog is now located at http://pa.rezendi.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://pa.rezendi.com/feeds/posts/default.

My love/hate relationship with the iPhone SDK

2010-04-16T06:52:00.001-07:00

There is a lot to hate about the iPhone SDK. But there's also a lot to love.

My app iTravel goes out and gets Wikitravel pages, and then gets subpages in the background. (eg if you ask for "New York City", it'll also go out and get "Manhattan", "Upper West Side", etc.) It also plots listings (sights, restaurants, etc.) for all these pages on a map. I wanted the background thread that was loading this data to automatically a new page's listings to the map, if the viewer was using one; so they can go to "New York City", go to the map, and then watch Manhattan slowly get barnacled by map annotations, one neighbourhood at a time.

I thought this was going to be difficult. I couldn't have been more wrong. Here's the background-thread code, in its entirety:


-(void) refreshMapIfActive {
 UIApplication *app = [UIApplication sharedApplication];
 iTravelRightAppDelegate *appDelegate = app.delegate;
 UINavigationController *controller = [appDelegate navigationController];
 NSArray *viewControllers = [controller viewControllers];
 UIViewController *currentController = [viewControllers lastObject];
 if ([currentController class] == [MapViewController class])
  [currentController performSelectorOnMainThread:@selector(showAnnotations:) withObject:nil waitUntilDone:NO];
}

I'd like to do this in Android, too...but a) their map implementation works a lot slower, b) I don't think there even is a method to get the currently active Activity.

Now, the "showAnnotations:" method within MapViewController is obviously trickier. For one thing, it's synchronized, lest the user try to filter a map just when a background thread is adding listings - not really a UI issue, since this usually takes all of 1-2 seconds:


-(void)doShowAnnotations:(NSArray*)annotationsToShow {
 //autorelease pool
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 
 @synchronized (self) {
  @try {
   NSArray *wikiPageMarkers = [WikiPage getPageMarkersWithin:mapView.region];
   
   BOOL added=NO;
   double pageLevel = [Settings getMapPageLevel];
   BOOL abovePageLevel = mapView.region.span.longitudeDelta > pageLevel || mapView.region.span.latitudeDelta > pageLevel;

   if (abovePageLevel && [mapView.annotations count] > [wikiPageMarkers count]) { //clear away low-level annotations
    [mapView performSelectorOnMainThread:@selector(removeAnnotations:) withObject:[annotations allObjects] waitUntilDone:YES];
    [annotations removeAllObjects];
   }
   else if (!abovePageLevel)
   {
    UITabBarItem *selected = [self.tabBar selectedItem];
    if (selected!=nil) {
     //first, remove all annotations that don't fit the selection
     NSMutableArray *toRemove = [NSMutableArray arrayWithCapacity:[mapView.annotations count]];
     for (NSObject *annotation in mapView.annotations) {
      if ([annotation class] == [Listing class]) {
       Listing *listing = (Listing*) annotation;
       if (!(selected.tag==MY && [listing isInMyListings] || selected.tag==[listing.category intValue]))
        [toRemove addObject:listing];
      }
     }
     [mapView performSelectorOnMainThread:@selector(removeAnnotations:) withObject:toRemove waitUntilDone:YES];
    }
    
    if (annotationsToShow==nil) { //if we don't have a specific request, get all the listings within the map's region
     NSNumber *category = selected==nil ? nil : [NSNumber numberWithInt:selected.tag];
     annotationsToShow = [ListingManager getListingsWithin:mapView.region forCategory:category];
    }

    //the following is incredibly messy because NSSet and NSMutableSet are unusable for our purposes.

What follows is one of the reasons I hate the SDK. Basically, I want to do some fairly basic set arithmetic to ensure that we remove undesired annotations from the map (but keep them in our local "annotations" set in case we need to add them again) and add new ones that are desired. Because the "-unionSet:" etc. methods on NSMutableSet don't work at all like you'd expect, though, I basically have to do that by hand. I'll skip over that messy part to the good stuff:


     NSMutableArray *thereNotRequested = [NSMutableArray arrayWithArray:mapView.annotations];
     for (annotation in mapView.annotations) {
      if ([requested objectForKey:[annotation title]] != nil)
       [thereNotRequested removeObject:annotation];
     }

     [mapView performSelectorOnMainThread:@selector(removeAnnotations:) withObject:thereNotRequested waitUntilDone:YES];

    if ([arrayToAdd count]>0) {
     [mapView performSelectorOnMainThread:@selector(addAnnotations:) withObject:arrayToAdd waitUntilDone:YES];
     added=YES;
    }

   if (!added)
    [self performSelectorOnMainThread:@selector(activityDone) withObject:nil waitUntilDone:NO];
  }
  @catch(NSException *exception) {
   [Util doLog:[NSString stringWithFormat:@"Warning: adding annotations to map view failed: %@", [exception reason]]];
   [self performSelectorOnMainThread:@selector(activityDone) withObject:nil waitUntilDone:NO];
  }
  @finally {
   [pool release];
  }
 }

SQLite on Android

2010-04-06T19:28:00.000-07:00

So a commenter on Android Market suggested I allow users store my app data on their SD card rather than phone memory. Great idea, I thought, and promptly went Googling to look for some example code. Alas, there wasn't any. So I wrote my own; and here it is for those who find themselves in a similar situation.

The basic Android model is for all Activity classes to have an associated DBHelper class. I don't like this at all; you waste all kinds of time writing and instantiating and opening and closing your DBHelpers, for the sake of (in my app) maybe twenty different database calls. So instead I went and created a singleton DB object. Here's the static code:


public class DB {
 private static DB instance;
    SQLiteDatabase mDB;
    DatabaseHelper mDbHelper;
    final Context mCtx;

    public static DB GetFor(Context context) {
        if (instance==null)
            instance = new DB(context);
        if (!instance.isOpen())
            instance.open();
        return instance;
    }
    
    public static void Close() {
         if (instance!=null && instance.isOpen())
             instance.close();
        instance=null;
    }

    /**
     * Database creation sql statement
     */
    static final String MESSAGE_CREATE =
        "create table Message (_id integer primary key autoincrement, "
   + "content text not null, dateCreated datetime not null, dateViewed datetime, "
   + "messageTitle text, messageType integer, sender text, recipient text); ";

//  [...other table definitions go here...]

    static final String DATABASE_NAME = "iTravel";
    static final int DATABASE_VERSION = 1;

(I call DB.Close() in the onDestroy() method of the app's Activities. Now, if you had multiple threads writing to the database simultaneously, this approach would probably get pretty messy in a hurry; fortunately, I don't.)

The Android SDK also includes a SQLiteOpenHelper object, which basically takes a Context object and returns a writeable database. I was a little irritated by the need to pass in a Context - it means you have a Context on hand to access the database at all - but presumed it was just necessary for some mysterious reason.

Not so mysterious at all. The bad news is, if you want your database to live on your phone's SD card, you can't use the SQLiteOpenHelper. The good news is, it's easy to write an SD-card-compatible variant, one that doesn't require any Context at all:


     static class DatabaseHelper{
     private SQLiteDatabase db;
     private Context mCtx;

     private DatabaseHelper(Context context) {
        mCtx=context;
     }

     public void open() {
         File dbDir=null, dbFile=null;
         if (Settings.DoSDDB() && Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED)) {
             dbDir = Environment.getExternalStorageDirectory();
             dbFile = new File(dbDir, "iTravel.sqlite");
         }
         else
             dbFile = mCtx.getDatabasePath("iTravel");

         if (dbFile.exists()) {
             Log.i("SQLiteHelper", "Opening database at "+dbFile);
             db = SQLiteDatabase.openOrCreateDatabase(dbFile, null);
             if (DATABASE_VERSION > db.getVersion())
                 upgrade();
          }
          else {
              Log.i("SQLiteHelper", "Creating database at "+dbFile);
              db = SQLiteDatabase.openOrCreateDatabase(dbFile, null);
              create();
          }         
     }
        
     public void close() {
         db.close();
     }

     public void create() {
         Log.w(""+this, "Creating Database "+db.getPath());
         db.execSQL(MESSAGE_CREATE);
//          ...other tables go here
         db.setVersion(DATABASE_VERSION);
     }

     public void upgrade() {
         Log.w(""+this, "Upgrading database "+db.getPath() +" from version " + db.getVersion() + " to "
                + DATABASE_VERSION + ", which will destroy all old data");
         db.execSQL("DROP TABLE IF EXISTS Message");
//       ...other tables go here
         create();
     }

     public SQLiteDatabase getWritableDatabase() {
        if (db==null)
            open();
        return db;
     }

Turns out the only thing we ever needed that Context for was its "getDatabasePath()" method, as that varies by application; but if you're using the SD card, you don't need that at all. (The above implementation supports both SD-card and phone-memory databases. Just in case.)

So what happens in the DB object's instance(s)? Easy enough -


    public DB(Context ctx) {
        this.mCtx = ctx;     
    }

    public DB open() throws SQLException {
        if (mDbHelper==null)
            mDbHelper = new DatabaseHelper(mCtx);
        if (mDB==null || !mDB.isOpen())
            mDB = mDbHelper.getWritableDatabase();
        return this;
    }

    public void close() {
        mDbHelper.close();
    }

    public boolean isOpen() {
        return mDB!=null && mDB.isOpen();
    }

    public boolean deleteAll() {
        mDB.delete("Message", null, null);
//      ...other tables go here
        return true;
    }

    public Message[] fetchMessages(String where, String[] args) throws SQLException {
        Cursor cursor =  mDB.query(true, "Message",
          new String[] {"_id", "messageTitle", "content" },
          where, args, null, null, "dateCreated desc", null);

        Message[] messages = new Message[cursor.getCount()];
        cursor.moveToFirst();
        int i=0;
        while (!cursor.isAfterLast()) {
            messages[i++] = new Message(cursor.getString(1), cursor.getString(2));
            cursor.moveToNext();
        }
        cursor.close();
        return messages;
    }
     
    public void saveMessage(Message message) {
        ContentValues values = new ContentValues();
        values.put("messageTitle", message.getTitle());
        values.put("content", message.getData());
        values.put("messageType", message.getMessageType());
        values.put("dateCreated", System.currentTimeMillis());
        mDB.insert("Message", null, values);
    }

et voila: all your database access in one place, accessed by a simple DB.GetFor(Context context) call from anywhere in your app (and you don't even need the Context if you know the DB will live on the SD card!) and nicely abstracting out the crazy ten-positional-arguments-in-a-row "query" method on SQLiteDatabase.

Responding to zooms and pans in Android's MapView

2010-03-01T19:02:00.000-08:00

There's a curious lacuna in Android's MapView API: it's (relatively) easy to display a map, and overlay items atop a map; it's (relatively) easy to detect when an overlay item has been touched; but there's no straightforward way to work out when the user has touched anywhere else on the map. Because of the way MapView works, the usual onTouchListener() solution only works for one touch, and then fails.

There is, however, a solution. Not a pretty one, but it works. The solution is to use your own subclass of MapView:


public class ITRMapView extends MapView {
 public ITRMapView(android.content.Context context, android.util.AttributeSet attrs) {
  super(context, attrs);
 }

 public ITRMapView(android.content.Context context, android.util.AttributeSet attrs, int defStyle) {
  super(context, attrs, defStyle);
 }

 public ITRMapView(android.content.Context context, java.lang.String apiKey) {
  super(context, apiKey);
 }
}

and within that subclass, override onTouchEvent. You're probably only interested in the UP action:


 public boolean onTouchEvent(MotionEvent ev) {
  if (ev.getAction()==MotionEvent.ACTION_UP) {
   //do your thing
  }
  return super.onTouchEvent(ev);
 }

But what if you want to detect zoom actions as well as touches? Simple, thought I: just override onDraw() and do the same thing. But you can't - MapView's onDraw() is final!

Catastrophe? Not quite. It turns out that overriding dispatchDraw() works just fine:


 int oldZoomLevel=-1;

 public void dispatchDraw(Canvas canvas) {
  super.dispatchDraw(canvas);
  if (getZoomLevel() != oldZoomLevel) {
   //do your thing
   oldZoomLevel = getZoomLevel();
  }
 }

Et voila - you can programmatically detect and respond when the user pans and/or zooms your map. Really not so hard after all.

Android vs. iPhone: A Developer's Perspective, part II

2010-02-08T12:12:00.000-08:00

Android vs. iPhone: A Programmer's Perspective - II

(See also Part I.)

OS features

The big winner here is Android, due to its multitasking. You can call other apps, eg a browser or a file-system picker, get results from them, and use those results in your own app; all these things are completely impossible on the iPhone, where (aside from a few special cases like iTunes) only one app may run at a time. (And even if you want to sacrifice yourself to launch another app, you can only do so in very restricted circumstances - if they have registered a URL scheme.)

The browser special-case is worth mentioning; you can include browser windows in your own app, and mine do so in a few different places - but this is often not as full-featured or convenient to the user as opening up the full Safari browser.

You can also write Android services that run in the background, and you can launch them at boot time (if the user permits) by registering for the BOOT_COMPLETED intent. What it doesn't really, provide, though, is "push" notifications (other than by faking it with eg Comet HTTP Push) which the iPhone does offer. That's the iPhone's only advantage in this category, though.

Phone features

The iPhone is locked down. You don't get direct Bluetooth API access; you do in Android. You don't get direct SMS access; you do in Android. For security reasons, they claim in Cupertino. At least (like Android) it now lets you access the proximity sensor.

But to its credit, the features it does offer are a joy to work with. In particular, the built-in camera/preview screen (for iPhone) / picture selector (for iPod Touch) is excellent, and requires all of a half-dozen lines of code to launch and respond to. The Android camera code, last I looked at it, was much more complex.

Location management is a little messy and complex on both systems, but overall Android's registration model is easier to work with than the iPhone's delegation model.

The iPhone SDK comes with this daft notion that all settings for all apps should probably be in a single System Settings screen accessible from the main menu; you can roll your own, but it's inconvenient. Android, by contrast, lets you create a settings screen by simply writing XML, no Java required unless you want to customize it. On the other hand, the iPhone simply makes "your default settings" available, whereas Android provides the possibility of multiple sets, which is doubtless more flexible and powerful but also more annoying to work with.

Accessing system and app resources (eg image files) is a little counterintuitive on Android; at compile time, it scans a predetermined bunch of directories, and automatically builds an "R" file with a bunch of final static ints, each of which uniquely identifies a resource; you then use those in code to access resources. (There's also an Android.R for built-in-resources.) This is confusing at first, but fine once you get used to it.

The iPhone makes the basics easy for you in code -

[Image imageNamed:@"myImage.png"]

- but if you want to go beyond that, the whole resource-bundling thing is less than intuitive, and while I had no trouble accessing bundle resources, I never felt like I had a clear idea of what was actually going on, unlike with Android.

Screen building

No sense pussyfooting around: when it comes to actually building the screens of your app, the iPhone has a massive advantage. It provides an excellent WYSIWYG tool, and the components it offers - buttons, lists, etc - mostly just look a whole lot nicer and sexier than the Android ones.

(That said, I have two minor complaints about the iPhone UI components: 1) No drop-down options in menus - instead you either have to code an ActionView or use one of the huge screen-eating spinners. 2) The absence of a border around TextViews does not look good and just serves to confuse users.)

In general, though, the iPhone wins here. The delegate model of TableViewController gives you powerful and fine-grained control far more easily than the adapter model of ListActivity. As far as "complicated, hard-to-work-with, but useful subclasses of your basic list view" goes, I'll take the iPhone's LocalizedIndexedCollation over Android's ExpandableListView, though I sure wish both were more developer-friendly.

And then there's maps. Jeez. In iPhone, if you want to add a custom marker for a map, then in the ViewController for that screen, you just override a method and write six lines of code:


- (MKAnnotationView *)mapView:(MKMapView *)myMapView viewForAnnotation:(id )annotation {
  NSString viewImageName=@"myImage.jpg";
  MKAnnotationView *myView = (MKAnnotationView*)[myMapView dequeueReusableAnnotationViewWithIdentifier:viewImageName];
  if (myView==nil) {
   myView = [[[MKAnnotationView alloc] initWithAnnotation:annotation reuseIdentifier:viewImageName] autorelease];
   myView.image = [UIImage imageNamed:viewImageName];
  }
  return myView;
}

In Android, first you have to write a whole new inner class that extends ItemizedOverlay, eg:


 class ListingsOverlay extends ItemizedOverlay {
  private ArrayList overlays=new ArrayList();

  public ListingsOverlay(android.graphics.drawable.Drawable defaultMarker) {
   super(defaultMarker);
  }

  public void addOverlay(OverlayItem overlay, Drawable marker) {
   super.boundCenterBottom(marker);
   overlay.setMarker(marker);
   overlays.add(overlay);
  }

  // necessary because populate() is protected
  public void doPopulate() {
   populate();
  }

  @Override
  protected OverlayItem createItem(int i) {
   return(overlays.get(i));
  }

  @Override
  public int size() {
   return(overlays.size());
  }

and then something like this:


      mapView = (MapView) findViewById(R.id.mapview);
      mapOverlays = mapView.getOverlays();
      mapOverlays.removeAll(mapOverlays);

      Drawable drawable = getResources().getDrawable(R.drawable.map_fave);
      itemizedOverlay = new ListingsOverlay(drawable);
      OverlayItem overlay = new OverlayItem(point, mappable.getIDString(), mappable.getMapDetailText());
      Drawable marker = MappableItem.GetMarkerForMappable(ITRMapView.this, mappable.getCategory());
      itemizedOverlay.addOverlay(overlay, marker);
      itemizedOverlay.doPopulate();

Menus and navigation are also easier and prettier on the iPhone; you can add sleek-looking buttons and toolbars and simply set them to call the selector of your choice, and you get a great NavigationController for iTunes-like interfaces, plus sexy animation. No real equivalent on Android.

On the other hand, Android's XML layouts, while tedious and irritating, and not as pretty or near as exact as the iPhone's WYSIWYG, do work well once you get the hang of them - and they make it much easier to support multiple screen sizes and different orientations. (My iPhone app simply doesn't do landscape orientation; my Android app handles it almost perfectly, without me ever having thought about it.) This wasn't a big deal for the iPhone until last month - but apps that previously were confident of a 320x480 screen now have to deal with the iPad.

The Internet

Accessing web services and launching in-app web views is easy and effective in both Android and iPhone. Edge to the latter, though; there are a couple of weird little bugs with Android's WebViews (though they can be worked around with ease) and the iPhone gives you both more SDK options and better documentation.

Release

Building an iPhone app is kind of scary. You're suddenly reminded that under the hood it's terrifying C++; the "Build" screens are full of dozens if not hundreds of byzantine, cryptic, intimidating options for compiling, precompiling, linking, etc., and you find yourself desperately hoping you've set up your import libraries perfectly and suddenly very careful not to touch anything.

That said, XCode works really well. (Have I mentioned that debugging is far easier with the iPhone SDK? Debugging is far easier with the iPhone SDK. With Android I usually wind up resorting to debugging with log messages.) What does not work really well is Apple's paranoid certification hegemony. God forbid that anyone run an app without going through the App Store!

So you need to go to Apple's site and futz around with it and with device IDs and create and download separate certificates for debug and release, and your temporary "provisioning" device certificates expire every three months, and while it is theoretically possible to build an app for someone else's device, email it to them, and have them install it, I have yet to actually succeed at this, despite repeated attempts. (It's somewhat easier if their device is plugged in to your machine.)

You know how it works on Android?
- You build your app.
- You sign your app. (Which Eclipse can take care of with a simple wizard.)
- Anyone in the whole world who wants to can now download and run the app.

There's a slight pitfall if you're working with Google Maps - you have to jump through hoops like Apple's to create separate debug and release Maps API Keys, and ensure you're using the right one - but by and large, it's miles easier and better than trying to finagle your way into Apple's walled garden.

Plus, if you've built an app and released it, and found some sort of subtle bug? With Android, you can fix that and have a new version up on the Android Market in five minutes. With Apple, it's ... a week? A month? Who knows? App Store approval is an infuriating black box.

Overall

They're both excellent systems. They both have their pros and cons. Overall I would rate the iPhone as better, both in terms of what you can do with it and how - but Android is superior in fundamental ways (eg multitasking and memory management) and catching up fast in terms of results. If Apple doesn't watch out, and move fast, they're going to find themselves superseded soon. Maybe this year.

Android vs. iPhone: A Developer's Perspective, part I

2010-02-07T20:30:00.001-08:00

Android vs. iPhone: A Programmer's Perspective

(See also Part II.)

I've spent the last month or so building both Android and iPhone versions of my app iTravel. (See http://wetravelright.com/ for details and links.) Which gives me a pretty good perspective from which to compare and contrast the Android and iPhone environments and SDKs. Hence I give you the following head-to-head analysis, from a developer's point of view:

Language

Non-programmers often think that one's language of choice is a big deal, but really, once you've learned two or three programming languages, picking up another is generally something you can do in a day or two. That said, there are often substantive differences. And this is definitely true of Java (for Android) and Objective-C (for iPhone.)

Let's start off with the really annoying stuff: Objective-C's memory management. By which I mean, its complete lack of any. Programmers have to manually allocate and release memory when writing for the iPhone SDK, which is positively medieval. If you fail to do so, and there are many pitfalls, then you leak memory which is lost until the device reboots. This is awful. (And it's no longer true of the Mac SDK, incidentally; but the iPhone is behind the times.)

There are other annoyances. You have two files to contend with for every class - a .h and a .c file. Which is inconvenient and complicating and inelegant. And suppose you have a basic, bog-standard instance variable. You generally wind up declaring it in, count 'em, not one, not two, not three, but four different places.

In your .h:


{
 NSObject *object
}

@property (nonatomic, retain) NSObject *object

In your .c;


@synthesize object

and later, in dealloc(),


[object release];

Whereas with Java, you have one single .java file, which in general will have


private Object object;
public Object getObject() { return object; }
private void setObject(Object o) { object=o; }

all in one place. I know which one I think is easier.

But. On the other hand. Objective-C is sort of the bastard son of C, which is awful, and Smalltalk, which is awesome. As a result, it has Smalltalk-like features like selectors:


[caller performSelector:@selector(myFunctionName)]

...in short, you can use functions as (more or less, ish) first-class objects. Try that in Java and if memory serves you'll most likely wind up in the irritating labyrinth of reflection. Plus, you get options like "doesNotRecognizeSelector:", which can be easily misused, but is potentially very powerful, and does not exist in Java.

On the other hand, Objective C is really annoyingly logorrheic (meaning wordy) especially when it comes to string handlers. Suppose you have strings A and B, and you wish to combine them into string C. In Java, the syntax is


C=A+B;

whereas in Objective-C, you type


C = [A stringByAppendingString: B]

Or suppose you want the location of the last slash in string A. Java:


n=A.lastIndexOf("/");

Objective-C:


n = [A range ofString:@"/" options:NSBackwardSearch].location;

I much prefer Java's syntax and simplicity. But I do admire Objective-C's flexibility.

Development environment

By this I mean: the "integrated development environment" in which coders work; the documentation for the IDE, the language, and the libraries; the testing and source-code support; and all the stuff that is meant to help you write better code faster.

The Android and iPhone IDEs and documentation really incarnate the attitudes of the two companies in question. Android doesn't exactly have an IDE of its own, although they recommend that you use the Android plug-in for the open-source Eclipse IDE, which is slow, irritating, and buggy in various minor ways. The documentation is written by smart people for smart people, with little handholding. Flashy graphics are minimal to nonexistent. And a lot of important stuff is still handled by tools meant to be run from a shell rather than a GUI. But the search function is excellent.

Apple's IDE is slick, seamless and powerful. It comes with a visual tool to help you lay out the screens of your app. The documentation is full of step-by-step guides (although they are often oddly lacking or confusing) and high-quality graphics and other visualizations.

I have many complaints about both. Eclipse is slow and annoying, and I could only get Android's JUnit test harness to run successfully from a terminal window, rather than the IDE; similarly, I had to use shell tools to sign packages, get a fingerprint for a Maps IDE, install a package on my phone, etc. All of which really calls into question the I in IDE.

On the other hand, at last the external unit-testing actually works; XCode's built-in harness is so bad that Google built and released an entirely separate one, which has the advantage of actually functioning correctly. On the other hand, its Subversion integration is excellent, which is not true of Eclipse.

Both have plenty of official and unofficial online support, as well, at official support sites and places like Stack Overflow. Android's open-source ethos gives it a big advantage in terms of external packages, though; for instance, if you want to build a barcode scanner into an Android app, there's a whole open-source library out there for you, ready to be plugged in. For the iPhone? You'll have to roll your own. Sorry.

Multithreading

In phone apps multithreading is key, because the phone needs to remain as responsive as possible, so you need to do your heavy lifting behind the scenes, outside the main UI thread.

Both the iPhone SDK and Android support multithreading, but the latter's is much more convenient, especially if you want to call back to the main thread once your background thread has done its thing. On the iPhone, you have to do something like:


-(void) doWebView {
 NSThread* htmlThread = [[NSThread alloc] initWithTarget:self selector:@selector(loadHtml) object:nil];
 [htmlThread start];
 [htmlThread release];
}

-(void) loadHtml {
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 NSString *html = doUnroll ? [self getUnrolledData] : root.data;
 html=[NSString stringWithFormat: @"%@%@</body></html>", [Util getBaseHtml], html];
 [self performSelectorOnMainThread:@selector(setHtml:) withObject:html waitUntilDone:NO];
 [pool release];
}

-(void) setHtml:(NSString*)html {
 [webView loadHTMLString:html baseURL:nil];
 [webView sizeToFit];
 [self.tableView setTableHeaderView:webView];
}

Whereas on Android, you can use Java's equally irritating Runnable() framework, but Android provides an extremely convenient (and quite flexible) short form. Just subclass AsyncTask in an inner class:


        new LoadHtmlTask().execute();

    class LoadHtmlTask extends AsyncTask {
     protected String doInBackground(String... strings) {
  String headerData = Settings.GetHtmlPrefix() + (unrolled ? getUnrolledData(viewRoot) : viewRoot.getData());
  return headerData;
     }     

     protected void onPostExecute(String results) {
  mHeaderView.loadDataWithBaseURL("local", headerData, "text/html", "utf-8", "");
     }
    }

which seems much more encapsulated and intuitive to me.

Persistence

On paper, the iPhone environment has a big advantage here: it features the Core Data object-persistence layer above the SQLite database, whereas Android requires direct DB access.

For me, though, direct DB access was not awful, and given the constraints of my app, arguably simpler than jumping through all of Core Data's hoops - using the separate tool to declare a data model, having to rebuild your custom code every time you add a column, etc. All that without even getting thread safety.

However, I'm totally comfortable writing SQL, not all developers are, and my app had pretty straightforward DB requirements. Core Data is undeniably more elegant and ultimately better. Plus you get nifty little features like shake-to-undo, semi-automatic migration data models in installed apps, etc. And it's not like the Android tools are particularly easy to work with. Check out the method in android.database.sqlite.SQLiteDatabase you use to perform a query:


public Cursor query (boolean distinct, String table, String[] columns, String selection, String[] selectionArgs, String groupBy, String having, String orderBy, String limit)

As a (Google employee) friend of mine said, "Holy positional parameters, Batman!" Needless to say, one quickly wraps this monstrosity in other methods less prone to grievous error...

Part II of this post compares and contrasts system features, phone features, settings and resources, screen building, internet connectivity, and the app install/release process. (It does not compare and contrast graphics programming, as my apps are data-heavy not graphics-heavy.) Don't touch that dial.

Back in the Android saddle

2010-01-31T16:09:00.000-08:00

So now that versions 2.0 of my iPhone app are up and running on the App Store, I've finally started writing an Android version. You may recall that this blog was supposed to be primarily about Android development from the get-go. We apologize for the eight-month sidetrack.

Anyway, It's been going quite well. Both the Android and iPhone SDK have their pros and cons. I like XCode better than Eclipse, and I generally (though not always) prefer Core Data to direct DB queries; on the other hand, string processing is far easier in Java, Android's multithreading is easier to work with, I vastly prefer single .java files vs twinned .h/.c files, and I love not having to worry about manual memory management.

The Android version is now mostly functionally complete. Things I have (sometimes re) learned which may be of interest:

Both the Android and iPhone OSes restrict background threads from directly calling the user interface. With the iPhone, you need to use "performSelectorOnMainThread:"; with Android, you need to use "postInvalidate()" rather than "invalidate()" to get a View to redraw itself.

I'm experimenting with a database-access model wherein all my Activities do the following:


 protected DB db;

 @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
     db = new DB(this);
     db.open();
    }

 @Override
    protected void onResume() {
  super.onResume();
     db.open();
    }
    
 @Override
    protected void onPause() {
  super.onPause();
     db.close();     
    }

wherein DB encapsulates the database, and all database calls go through it. This is a variant of the "DbHelper" model that you see in the Android tutorials, and imho and simpler and better one in most circumstances. It's mostly implemented as per the above in abstract superclasses of the instantiated activities.

You then have accessor methods such as


  db.saveListing(listing);

which is handled pretty much as per the tutorials, and


  Listing[] listings = db.fetchListingsForPage(Util.SQLize(pageURL));

which calls


    public Listing[] fetchListingsForPage(String pageURL) throws SQLException {
     return fetchListingsFor("pageURL LIKE '"+pageURL+"%'", (String[])null);
    }

which in turn calls the generic


    public Listing[] fetchListingsFor(String where, String... args) throws SQLException {
        Cursor cursor =  mDB.query(true, "Listing",
          new String[] {"_id", "name", "data", "isFlagged", "category", "address", "url",
          "pageURL", "sectionName", "sectionNumber", "location", "downloadDate" },
                where, args, null, null, null, null);

     Listing[] listings = new Listing[cursor.getCount()];
     cursor.moveToFirst();
  int i=0;
  while (!cursor.isAfterLast()) {
   listings[i++] = new Listing(cursor.getLong(0), cursor.getString(1), cursor.getString(2), cursor.getInt(3),
     cursor.getInt(4), cursor.getString(5), cursor.getString(6), cursor.getString(7), cursor.getString(8),
     cursor.getString(8), cursor.getString(10), cursor.getLong(11));
   cursor.moveToNext();
  }
  cursor.close();
  return listings;
    }

which is in course incredibly ugly, but at least it only happens in one place.

Here's an Activity that serves as a browser within your app, in its entirety.
Layout:



 android:layout_width="fill_parent"
 android:layout_height="fill_parent"/>

Code:


public class WebDisplay extends ITRActivity {
 public static String KEY_URL = "url";
 public static String KEY_DATA = "data";
 
 String mUrl;
 String mData;
 
 @Override
 public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.web);
  WebView web = (WebView) findViewById(R.id.web);

     Bundle extras = getIntent().getExtras();
  mUrl = extras == null ? null : extras.getString(KEY_URL);
  mData = extras == null ? null : extras.getString(KEY_DATA);
  
  if (mUrl!=null)
   web.loadUrl(mUrl);
  else if (mData!=null)
   web.loadData(mData.replace("%","%"), "text/html", "utf-8");  
    } 
}

More to come when I release v1.0, which should happen in the next ten days.

Using Core Data in a multithreaded environment.

2010-01-18T18:24:00.001-08:00

You have to do a lot of iPhone stuff in background threads, to maintain a snappily responsive user interface. But if you're using Core Data, well - to quote the docs:

Managed objects are not thread safe [...] Core Data does not present a situation where reads are "safe" but changes are "dangerous"—every operation is "dangerous" because every operation can trigger faulting.

Sound intimidating? No worries: it's a piece of cake. Just wrap the code where you get your ManagedObjectContext in a method something like this:


@implementation Util

+(NSManagedObjectContext*)getManagedObjectContext {
 UIApplication *app = [UIApplication sharedApplication];
 MyAppDelegate *appDelegate = app.delegate;
 if ([NSThread isMainThread])
  return [appDelegate managedObjectContext];
 else
  return [appDelegate getMOCFor:[NSThread currentThread]];
}

and add the following method to your application delegate:
(where "threadMOCs", obviously, is a properly defined and synthesized ivar.)


- (NSManagedObjectContext*) getMOCFor:(NSThread*) thread {
 if (!threadMOCs)
  self.threadMOCs=[NSMutableDictionary dictionaryWithCapacity:16];
 
 NSNumber *threadHash = [NSNumber numberWithInt:[thread hash]];
 if ([threadMOCs objectForKey:threadHash]==nil) {
  NSManagedObjectContext *newMOC =  [[NSManagedObjectContext alloc] init];
  NSError *error=nil;
  NSURL *storeUrl = [NSURL fileURLWithPath: [[self applicationDocumentsDirectory] stringByAppendingPathComponent: @"myDBName.sqlite"]];  
  NSManagedObjectModel *model = [self managedObjectModel];
  NSPersistentStoreCoordinator* threadPSC = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: model];
  if (![threadPSC addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeUrl options:nil error:&error])
   { //handle error here }

  [newMOC setPersistentStoreCoordinator: threadPSC];
  [threadMOCs setObject:newMOC forKey:threadHash];
 }
 return [threadMOCs objectForKey:threadHash];
}

Et voila! A new object context and persistent store coordinare for every thread, which gives you full concurrent access to your data. (Though you probably still have to be careful about passing managed objects across threads...)

How to store images larger than 1 megabyte in Google App Engine

2009-11-30T14:18:00.001-08:00

Over the summer, Google App Engine raised its limits for web requests and responses from 1MB to 10MB, but kept the maximum size of any single database element at 1MB. If you try to exceed this, you'll get a MemoryError. You can find a fair amount of grief and woe and gnashing of teeth and wearing of sackcloth and ashes about this online.

Which is kind of surprising, because it's not that hard to break files up into chunks and store those chunks in the database separately. Here's what I did today for my current project, which stores data - including photos - uploaded from smartphones:

First, we have to receive the uploaded image. Our uploads are two-phase - first data, then a photo - for various reasons. The data upload includes the image's file name; the photo upload is a basic form/multipart POST with exactly one argument (the filename) and its value (the file).

So, in "main.py":


class SaveImage(webapp.RequestHandler):
  def post(self):
    entryHandler=ec.EntryHandler()
    for arg in self.request.arguments():
      file = self.request.get(arg)
      response = entryHandler.saveImage(arg,file)
      self.response.out.write(response)

and in "ec.py":


class ImageChunk(db.Model):
  entryRef = db.ReferenceProperty(Entry)
  chunkIndex = db.IntegerProperty()
  chunk = db.BlobProperty()

class EntryHandler:
  def saveImage(self, fileName, file):
      results = Entry.all().filter("photoPath =", fileName).fetch(1)
      if len(results)==0:
        logging.warning("Error - could not find the entry associated with image name "+fileName)
        return "Failed"
      else:
        MaxBTSize=1000000
        entry = results[0]
        marker=0
        chunks=[]
        while marker*MaxBTSize<len(file):
          if MaxBTSize*(marker+1)>len(file):
            chunk = ImageChunk(entryRef=entry, chunkIndex=marker, chunk=db.Blob(file[MaxBTSize*marker:]))
          else:
            chunk = ImageChunk(entryRef=entry, chunkIndex=marker, chunk=db.Blob(file[MaxBTSize*marker:MaxBTSize*(marker+1)]))
          chunk.put()
          marker+=1
        logging.info("Successfully received image "+fileName)
        return "Successfully received image "+fileName

Pretty basic stuff: we chop the image up at each 1,000,000-byte mark, and put each chunk into its own ImageChunk DB object.

Then, when we need to retrieve the image, in 'main.py':


class ShowImageWithKey(webapp.RequestHandler):
  def get(self):
    key = self.request.get('entryKey')
    entryHandler = ec.EntryHandler()
    image = entryHandler.getImageByEntryKey(key)
    if image is not None:
      self.response.headers['Content-Type'] = 'image/jpeg'
      self.response.out.write(image)

and in 'ec.py':


  def getImageByEntryKey(self, key):
    chunks = db.GqlQuery("SELECT * FROM ImageChunk WHERE entryRef = :1 ORDER BY chunkIndex", key).fetch(100)
    if len(chunks)==0:
      return None

    image=""
    for chunkRow in chunks:
      image+=chunkRow.chunk
    return image

Since db.Blob is a subtype of str, that's all you have to do. I don't understand why some people are so upset about this: it's mildly annoying that I had to write the above, but hardly crippling. At least with JPEGs, which is what we use. (But I don't see why any other file type would be more difficult; they're ultimately all just a bunch of bytes). Could hardly be easier ... well, until App Engine rolls out their large file service.

(eta, Dec 14: which came out today! Meaning you can now disregard all the above and just use the new Blobstore instead.)

(eta, Dec 16: mmm, maybe not. Looked at the Blobstore in detail today, and it's really best suited for browser projects, not app or web-service stuff. The API for the blobs is very limited, and you can only access them via one-time-only URLs that App Engine puts in your HTML. You could scrape that, granted, but that's a pain in the ass, no less inelegant than the image-chunking solution above. It's experimental and subject to change, too. I think I'll hold out until its API improves.)

to infinity, and beyond!

2009-11-04T08:34:00.000-08:00

I am pleased to report that my pet-project iPhone app, iTravelFree, has passed the stern inspection of Apple's App Store and is now available for download worldwide. For app links, a screenshot-laden tutorial, and help and FAQ files, see here: www.wetravelright.com.

(Yeah, crappy URL, I know, but all the good ones were taken.)

Since this is my tech blog let me wax about its architecture a bit. The iPhone app is pretty straightforward: basically, it's a bunch of TableViewControllers, many of which include WebViews, along with a MapViewController, all pointing to a bunch of CoreData records. Nothing extraordinarily fancy by any means.

The server side is more interesting: it's a Google App Engine service, written in Python, that fetches, caches, and parses Wikitravel pages for the app. This gives me a single point of access to the data flow, lets me do things like convert addresses to lat/long location, cuts down on bandwidth for both Wikitravel (thanks to the caching) and the phone app (thanks to the parsing and stripping out of extraneous info.)

The general architecture - phone app plus App Engine service - is actually really powerful and easy to work with. Basically, it's a distributed version of the classic Model-View-Controller architecture, where the phone is the view, the App Engine service is the controller, and whatever data you're accessing is the model. This lets you do all the heavy-lifting computation on the server side, which is where it belongs, and keep the phone (and its puny processor) focused almost purely on the UI.

I do have some reservations about the BigTable data store that App Engine uses, but they don't apply to projects like this, with relatively simple storage requirements and no data mining.

I wrote it in, hrmm, about six weeks all told, starting in July. (Obviously it's been much more than six weeks since then, but I had full-time work starting August so could only work on this in fits and spurts on the side.)

Anyway - the app is in pretty good shape, but there's more work to be done on the server side, so it's still basically in beta test. Take a look, download it, play around, and let me know what you think -

jQuery, how do I love thee?

2009-10-14T14:11:00.001-07:00

So I spent a few days doing some JavaScript, which is not my favourite thing. Or at least it didn't use to be. But now that I have discovered JQuery, I gotta say, it's a whole lot more tolerable than it used to be.

JQuery makes some things that I would previous have considered all but impossible downright easy. Take drag-and-drop inside the browser, f'rinstance. To do it yourself, you'd have to deal with, jeez, I don't even know what, DOM craziness, layers, who knows. In jQuery? Well, lemme give you a quick example, stripped of all the actual business logic, of a drag-and-drop form builder:


<html><head>
     <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.js"></script>
 <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.js"></script>

    <style type="text/css">
        .columns:after {
            content: ".";
            display: block;
            height: 0;
            clear: both;
            visibility: hidden;
        }
        * html .columns {height: 1%;}
        .columns{ display:inline-block; }
        .columns{ display:block; }
        .columns .column{
          float:left;
          display:inline;
          min-height:360px;
        }
        .columns .last{ float:right; }
        .columns .first{ width:180px; background-color:#ffeeee; }
        .columns .second{ width:280px; margin-left:10px; background-color:#eeffee; }
        .columns .last{ width:210px; background-color:#eeeeff}

        .footers{ display:inline-block; }
        .footers{ display:block; }
        .footers .footer{
          float:left;
          display:inline;
        }
        .footers .last{ float:right; }
        .footers .first{ width:180px; background-color:#eeeeee; }
        .footers .second{ width:280px; margin-left:10px; background-color:#eeeeee; }
        .footers .last{ width:210px; background-color:#eeeeee}

        .formLineEdit { text-align: right; }
        .optionLabel { float:right; text-align: right; }
        .label { font-weight: bold; vertical-align: text-top; }
        .formInput { text-align: right; vertical-align: text-top; }
        .editHeader { text-align: right; }
        .selectOption { text-align: right; }
        #error { text-align: center; color: #ff0000; }
        #success { text-align: center; color: #00ff00; }
        #listForms { float: left; text-align: left; }
        #viewHelp { float: right; text-align: right; }
        #inputOptions { text-align: right; }
        #detailHeader { text-align: right; }
        #formName {background-color: #eeeeee; }
        #formVersionNumber {background-color: #eeeeee; }
        #formSubmitButton {text-align:right; background-color: #eeeeee; }
    </style>

    <script>
        var totalItems=0;
        var currentlyEditing=null;
        var lastEdited=null;

        $(function() {
            //make divs created out of XML clickable
            var destClicked=false;
            $("#destination").mousedown( function() {
                if (!destClicked) { //only do this once, or it might get messy
                    $("#destination").children().each( function() {
                        $(this).bind("click", function() {
                            showEditDetailsFor($(this));
                        });
                    });
                }
                destClicked=true;
            });
            
            //set up drag-and-drop stuff
            $("#textInput").draggable(
                {   connectToSortable:'#destination',
                    cursor:'move',
                    helper:'clone',
                }
            );
            $("#longText").draggable(
                {   connectToSortable:'#destination',
                    cursor:'move',
                    helper:'clone',
                }
            );
            $("#selectMultiple").draggable(
                {   connectToSortable:'#destination',
                    cursor:'move',
                    helper:'clone',
                }
            );
            $("#selectOne").draggable(
                {   connectToSortable:'#destination',
                    cursor:'move',
                    helper:'clone',
                }
            );
            $("#destination").sortable(
                {
                    change: function(event, ui) {
                        ui.placeholder.css({visibility: 'visible', border : '2px solid yellow'});
                    },
                    start: function(event, ui) {
                        ui.placeholder.css({visibility: 'visible', border : '2px solid yellow'});
                        var tempID=ui.item.attr("id");
                        if (tempID.indexOf("_")==-1) {
                            tempID=tempID+"_"+totalItems++;
                            ui.item.attr({id:tempID});
                        }
                    },
                    stop: function(event, ui) {
                        //load element details, and ensure they'll show up again when this item is clicked
                        showEditDetailsFor(ui.item);
                        ui.item.bind("click", function() {
                            showEditDetailsFor(ui.item);
                        });
                    },
                }
            );
        });

        function showEditDetailsFor ( object ) {
//            object.effect("highlight", {}, 3000);
            currentlyEditing=object.attr("id");
            if (currentlyEditing==lastEdited)
                return;

            $(".formLineEdit").hide();
            $("#inputOptions").show();

            if (object.attr("id").indexOf("textInput")==0) {
                var inputLabel = $.trim(object.find(".label").text());
                var inputID = object.find("input[name=inputID]").val();
                if (inputLabel!="Text Input" || object.find("input[name=inputID]").attr("name")!="inputID") {
                    $("#textInputEdit").find("input[name=textInputLabel]").val(inputLabel);
                    $("#textInputEdit").find("input[name=textInputValue]").val(inputID);
                }
                $("#textInputEdit").show();
            }
            else if (object.attr("id").indexOf("longText")==0) {
                var inputLabel = $.trim(object.find(".label").text());
                var inputID = object.find("textarea:first").val();
                if (inputLabel!="Long Text" || inputID!="") {
                    $("#longTextEdit").find("input[name=longTextLabel]").val(inputLabel);
                    $("#longTextEdit").find("input[name=longTextValue]").val(inputID);
                }
                $("#longTextEdit").show();
            }
            else if (object.attr("id").indexOf("selectMultiple")==0) {
                var inputLabel = $.trim(object.find(".label:first").text());
                var inputID = object.find("input:last").attr("name");
                if (inputLabel!="Select Multiple" || inputID!="selectMulti") {
                    $("#selectMultiEdit").find("input[name=selectMultiLabel]").val(inputLabel);
                    $("#selectMultiEdit").find("input[name=selectMultiValue]").val(inputID);
                    blankOption=$("#selectMultiEdit > .selectOption").remove();
                    var addedChild=false;
                    object.children(".formInput").each( function() {
                        optionClone=blankOption.clone();
                        var optionLabel=$(this).find(".optionLabel").text();
                        optionClone.find("input[name=multiOptionLabel]").val(optionLabel);
                        var optionValue=$(this).find("input:first").attr("value");
                        optionClone.find("input[name=multiOptionValue]").val(optionValue);
                        cloneRemoveButton = optionClone.find("input[name=removeSelectMultiOption]");
                        cloneRemoveButton.bind("mouseup", function() {
                            $(this).parent().remove();
                        });
                        $("#selectMultiEdit").append(optionClone);
                        addedChild=true;
                    });
                    if (!addedChild)
                        $("#selectMultiEdit").append(blankOption);
                } //don't show defaults
                $("#selectMultiEdit").show();
            }
            else if (object.attr("id").indexOf("selectOne")==0) {
                var inputLabel = $.trim(object.find(".label:first").text());
                var inputID = object.find("input:last").attr("name");
                if (inputLabel!="Select One" || inputID!="selectOne") {
                    $("#selectOneEdit").find("input[name=selectOneLabel]").val(inputLabel);
                    $("#selectOneEdit").find("input[name=selectOneValue]").val(inputID);
                    blankOption=$("#selectOneEdit > .selectOption").remove();
                    var addedChild=false;
                    object.children(".formInput").each( function() {
                        optionClone=blankOption.clone();
                        var optionLabel=$(this).find(".optionLabel").text();
                        optionClone.find("input[name=oneOptionLabel]").val(optionLabel);
                        var optionValue=$(this).find("input:first").attr("value");
                        optionClone.find("input[name=oneOptionValue]").val(optionValue);
                        cloneRemoveButton = optionClone.find("input[name=removeSelectOneOption]");
                        cloneRemoveButton.bind("mouseup", function() {
                            $(this).parent().remove();
                        });
                        $("#selectOneEdit").append(optionClone);
                        addedChild=true;
                    });
                    if (!addedChild)
                        $("#selectOneEdit").append(blankOption);
                } //don't show defaults
                $("#selectOneEdit").show();
            }
            lastEdited=currentlyEditing;
        }


    </script>

</head>
<body>
<center><H3>Form Builder</H3></center>
<div id="success"></div>
<div id="error"></div>

<div id="header">
     
</div>
<P/>
<div class="columns">
    <div id="source" class="column first">
        <b>Form Elements</b><HR/>
        <div id="textInput" class="formLine">
            <div class="label">Text Input</div><div class="formInput"><input name="inputID" /></div>
        </div>
        <HR/>
        <div id="longText" class="formLine">
            <div class="label">Long Text</div>
            <div class="formInput"><textarea name="textarea"></textarea></div>
        </div>
        <HR/>
        <div id="selectMultiple" class="formLine">
            <div class="label">Select Multiple</div>
            <div class="formInput"> 
                <input type="checkbox" name="selectMulti" value="one" />
                <div class="optionLabel">One</div>
            </div>
            <div class="formInput"> 
                <BR/><input type="checkbox" name="selectMulti" value="two" />
                <div class="optionLabel">Two</div>
            </div>
        </div>
        <HR/>
        <div id="selectOne" class="formLine">
            <div class="label">Select One</div>
            <div class="formInput"> 
                <input type="radio" name="selectOne" value="one" />
                <div class="optionLabel">One</div>
            </div>
            <div class="formInput"> 
                <BR/><input type="radio" name="selectOne" value="two" />
                <div class="optionLabel">Two</div>
            </div>
        </div>
    </div> <!--source-->
    <div id="middle" class="column second">
        <b>Form</b> (drag elements here)
        <HR/>
        <div id="destination"> </div>
        <HR/>
    </div>
    <div id="details" class="column last">
        <div id="detailHeader"><b>Element Details</b><HR/></div>
        <div id="textInputEdit" class="formLineEdit">
            <div class="editHeader">
                <b>Text Input</b>
                <input type="submit" name="textInputSubmit" value="Done" />
                <input type="submit" name="delete" value="Delete" />
            </div>
            <BR/><a href="/formHelp#labels" target="_blank">Label</a><input name="textInputLabel" type="text" />
            <BR/><a href="/formHelp#ids" target="_blank">ID</a><input name="textInputValue" />
        </div>
        <div id="longTextEdit" class="formLineEdit">
            <div class="editHeader">
                <b>Long Text</b>
                <input type="submit" name="longTextSubmit" value="Done" />
                <input type="submit" name="delete" value="Delete" />
            </div>
            <BR/><a href="/formHelp#labels" target="_blank">Label</a><input name="longTextLabel" />
            <BR/><a href="/formHelp#ids" target="_blank">ID</a><input name="longTextValue" />
        </div>
        <div id="selectMultiEdit" class="formLineEdit">
            <div class="editHeader">
                <b>Select Multiple</b>
                <input type="submit" name="selectMultiSubmit" value="Done" />
                <input type="submit" name="delete" value="Delete" />
            </div>
            <BR/><a href="/formHelp#labels" target="_blank">Label</a><input name="selectMultiLabel" />
            <BR/><a href="/formHelp#ids" target="_blank">ID</a><input name="selectMultiValue" />
            <BR/><input type="submit" name="addSelectMultiOption" value="Add Option" />
            <HR/>
            <div id="selectMultiOption" class="selectOption">
                <i>Option</i>: <a href="/formHelp#editSelects" target="_blank">Name</a> <input name="multiOptionLabel" size=12/>
                <BR/><a href="/formHelp#editSelects" target="_blank">Value</a><input name="multiOptionValue" size=12/>
                <BR/><input type="submit" name="removeSelectMultiOption" value="Remove" />
                <HR/>
            </div>
        </div>
        <div id="selectOneEdit" class="formLineEdit">
            <div class="editHeader">
                <b>Select One</b>
                <input type="submit" name="selectOneSubmit" value="Done" />
                <input type="submit" name="delete" value="Delete" />
            </div>
            <BR/><a href="/formHelp#labels" target="_blank">Label</a><input name="selectOneLabel" />
            <BR/><a href="/formHelp#ids" target="_blank">ID</a><input name="selectOneValue" />
            <BR/><input type="submit" name="addSelectOneOption" value="Add Option" />
            <HR/>
            <div id="selectOneOption" class="selectOption">
                <i>Option</i>: <a href="/formHelp#editSelects" target="_blank">Name</a><input name="oneOptionLabel" size=12/>
                <BR/><a href="/formHelp#editSelects" target="_blank">Value</a><input name="oneOptionValue" size=12/>
                <BR/><input type="submit" name="removeSelectOneOption" value="Remove" />
                <HR/>
            </div>
        </div>
    </div> <!-- details-->
</div> <!--columns-->
<P/>
<div class="footers">
    <div id="formName" class="footer first"><b>Form Name</b>: <input name="formName" value="default" size=10 length=64 /></div>
    <div id="formVersionNumber" class="footer second">
        <b>Version Number</b>:
        <input name="formVersion">
    </div>
    <div id="formSubmitButton" class="footer last"><input type="submit" name="saveForm" value="Finished - Save Form!" /></div>
</div>

</body>
</html>

Pretty slick, eh?

What you do is, you drag form elements from the first column into the second column, where clones are inserted. (That way the element stays in the first column, so you can have an arbitrary number of instances in the second column.) One key thing to note is that clones do not inherit the clonee's bindings, so you have to bind any events after they're created, as shown above in the "stop" event of the "sortable" definition.

I would try to explain more, but either you already know JQuery reasonably well, in which case the above is probably pretty clear already, or you don't, in which case it will be Greek. So - just copy and paste the above as HTML, launch it in a browser, and play around with it; it should drag and drop right out of the box.

little bits of context-free iPhone code

2009-09-29T20:39:00.000-07:00

What it says on the label.

First, an example of how to handle Settings in an iPhone app. The way I do it is, I have a "Settings" class, with lots of class get-and-set methods, so at any time you can just call "[Settings getLanguage]"; then, I have a SettingsViewController, to change them. (Yes, you can register them to be changed in the iPhone's Settings app, but since you have to leave your app for that, this is annoying.)

Best of all, you don't have to use Core Data. Instead you can use the even simpler NSUserDefault class, like so:


@interface Settings : NSObject {

}
+(int)getListMax;
+(void) setListMax:(int)value;
+(NSString*)getLanguage;
+(void) setLanguage:(NSString*)language;
+(BOOL) doDownload;
+(void) setDoDownload:(BOOL)yesno;

@implementation Settings

//This method does all the work
+(id) getSettingFor:(NSString*)key withDefault:(id)defaultValue {
 NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
 id value = [defaults objectForKey:key];
 if (value==nil) {
  [defaults setObject:defaultValue forKey:key];
  return defaultValue;
 }
 return value;
}

+(int) getListMax {
 return [[Settings getSettingFor:@"listMax" withDefault:[NSNumber numberWithInt:500]] intValue];
}
+(void) setListMax:(int)value {
 [[NSUserDefaults standardUserDefaults] setObject:[NSNumber numberWithInt:value] forKey:@"listMax"];
}

+(NSString*) getLanguage {
 return [Settings getSettingFor:@"language" withDefault:@"en"];
}
+(void) setLanguage:(NSString*)language {
 [[NSUserDefaults standardUserDefaults] setObject:language forKey:@"language"];
}

+(BOOL) doDownload {
 return [[Settings getSettingFor:@"doDownload" withDefault:[NSNumber numberWithBool:YES]] boolValue];
}
+(void) setDoDownload:(BOOL)yesno {
 [[NSUserDefaults standardUserDefaults] setObject:[NSNumber numberWithBool:yesno] forKey:@"doDownload"];
}

[...no dealloc, as we never create an instance]

Note that you easily lazy-initialize all your defaults in code, and then let the user overwrite them. How, you ask? Via the SettingsViewController. Which you could create using the Layout Manager; but I prefer to do it programmatically, with a TableViewController, as it looks slicker much easier to add a Setting that way. Also, it lets me show you an example of my TableViewCell pattern. And while we're at it, a UIActionSheet example too. Voila:


@implementation SettingsViewController

- (void)viewDidLoad {
    [super viewDidLoad];
}

//Note that we save the settings as we leave the view
- (void)viewDidDisappear:(BOOL)animated {
 [super viewDidDisappear:animated];
 [[NSUserDefaults standardUserDefaults] synchronize];
}

#pragma mark -
#pragma mark TableView methods

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
 return 1;
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
 //# of settings
 return 3;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 if (indexPath.row==0) { //list max
  LabelTextFieldCell *cell = (LabelTextFieldCell *)[tableView dequeueReusableCellWithIdentifier:@"LabelTextField"];
  if (cell == nil)
   cell = [[[LabelTextFieldCell alloc] initWithFrame:CGRectZero reuseIdentifier:@"LabelTextField"] autorelease];
  
  cell.fieldName = @"listMax";
  cell.fieldDisplayName.text = @"List Max";
  cell.fieldValue.tag=indexPath.row;
  cell.fieldValue.keyboardType = UIKeyboardTypeURL;
  cell.fieldValue.autocapitalizationType = UITextAutocapitalizationTypeNone;
  cell.fieldValue.delegate=self;
  cell.fieldValue.text=[[NSNumber numberWithInt:[Settings getListMax]] stringValue];
 }
 else if (indexPath.row==1) { // do download
  SwitchCell *cell = (SwitchCell *)[tableView dequeueReusableCellWithIdentifier:@"Switch"];
  if (cell == nil)
   cell = [[[SwitchCell alloc] initWithFrame:CGRectZero reuseIdentifier:@"Switch"] autorelease];

  cell.fieldName = @"doDownload";
  cell.fieldDisplayName.text = @"Download pages";
  cell.mySwitch.tag=indexPath.row;
  cell.mySwitch.on=[Settings doDownload];
  cell.currentController = self; //we do this so we can respond to changes
 }
 else if (indexPath.row==3) { //language
  ButtonCell *cell = (ButtonCell *)[tableView dequeueReusableCellWithIdentifier:@"Button"];
  if (cell == nil)
   cell = [[[ButtonCell alloc] initWithFrame:CGRectZero reuseIdentifier:@"Button"] autorelease];

  cell.fieldName=@"language";
  cell.fieldDisplayName.text=@"Language";
  cell.button.tag=indexPath.row;
  [cell.button setTitle:[Settings getLanguageName] forState:UIControlStateNormal];
  [cell.button addTarget:self action:@selector(changeLanguage) forControlEvents:UIControlEventTouchUpInside];
 }
 else
  return nil;
}

#pragma mark -
#pragma mark UITextFieldDelegate

- (BOOL)textFieldShouldReturn:(UITextField *)textField {
 [textField resignFirstResponder];
 return YES;
}

- (void)textFieldDidEndEditing:(UITextField *)textField {
 if (textField.tag==0) {
  //TODO: check that it's a valid int!
  [Settings setListMax:[textField.text intValue]];
 }
}

#pragma mark -
#pragma mark Switch

-(void) valueChanged:(UISwitch*)aSwitch {
 if (aSwitch.tag==1) {
  [Settings setDoDownload:aSwitch.on];
 }
}

#pragma mark -
#pragma mark Button

-(void) changeLanguage {
 UIActionSheet *action = [[UIActionSheet alloc]
        initWithTitle:@"Select Language"
        delegate:self
        cancelButtonTitle:nil 
        destructiveButtonTitle:nil
        otherButtonTitles:nil];
 
 for (NSString* language in [Util getValidLanguageNames]) {
  [action addButtonWithTitle:language];
 }
 
 [action showInView:self.view];
}

#pragma mark -
#pragma mark UIActionSheetDelegate

- (void)actionSheet:(UIActionSheet *)actionSheet clickedButtonAtIndex:(NSInteger)buttonIndex {
 [Settings setLanguage:[[Util getValidLanguageValues] objectAtIndex:buttonIndex]];
 
 UIButton *button = (UIButton*) [self.tableView viewWithTag:6];
 [button setTitle:[actionSheet buttonTitleAtIndex:buttonIndex] forState:UIControlStateNormal];
 
 [actionSheet dismissWithClickedButtonIndex:buttonIndex animated:YES];
 [actionSheet release];
}

[...dealloc etc...]

That's pretty straightforward; build a table view, populate it with table view cells, and respond to the actions in the cells. But how do the cells work? Well, first look at their (theoretically abstract) common parent superclass, ITRTableViewCell:


@interface ITRTableViewCell : UITableViewCell {
 NSString *fieldName;
 UILabel *fieldDisplayName;
 UIViewController *currentController;
}

@property (nonatomic, retain) NSString *fieldName;
@property (nonatomic, retain) UILabel *fieldDisplayName;
@property (nonatomic, assign) UIViewController *currentController; //weak reference


@implementation ITRTableViewCell

@synthesize fieldName, fieldDisplayName, currentController;

-(id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString *)reuseIdentifier {
 [super initWithFrame:frame reuseIdentifier:reuseIdentifier];
 
 self.fieldDisplayName = [[UILabel alloc] init];
 fieldDisplayName.textAlignment = UITextAlignmentLeft;
 fieldDisplayName.adjustsFontSizeToFitWidth=YES;
 fieldDisplayName.minimumFontSize=8;
 fieldDisplayName.numberOfLines=2;
 fieldDisplayName.font = [UIFont systemFontOfSize:14];
 
 return self;
}

[...dealloc etc...]

which will make more sense when you look at its use in a subclass:


@interface LabelTextFieldCell : ITRTableViewCell {
 UITextField *fieldValue;
}

@property (nonatomic, retain) UITextField *fieldValue;


@implementation LabelTextFieldCell

@synthesize fieldValue;

-(id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString *)reuseIdentifier {
 [super initWithFrame:frame reuseIdentifier:reuseIdentifier];
 
 [self.contentView addSubview:fieldDisplayName];
 
 self.fieldValue = [[UITextField alloc] init];
 fieldValue.clearsOnBeginEditing = NO;
 fieldValue.enablesReturnKeyAutomatically = YES;
 fieldValue.returnKeyType = UIReturnKeyNext;
 fieldValue.autocapitalizationType = UITextAutocapitalizationTypeSentences;
 fieldValue.autocorrectionType = UITextAutocorrectionTypeNo;
 fieldValue.enablesReturnKeyAutomatically = YES;
 fieldValue.backgroundColor = [self getBackgroundColor];
 fieldValue.textColor = [self getTextColor];
 fieldValue.textAlignment = UITextAlignmentLeft;
 fieldValue.font = [UIFont systemFontOfSize:14];
 fieldValue.borderStyle = UITextBorderStyleBezel;
 [self.contentView addSubview:fieldValue];
 
 return self;
}

-(void)layoutSubviews {
 [super layoutSubviews];
 CGRect contentRect = self.contentView.bounds;
 CGFloat boundsX = contentRect.origin.x;
 CGRect frame;
 
 frame = CGRectMake(boundsX+10, 0, 140, 30);
 fieldDisplayName.frame = frame;
 
 frame = CGRectMake(boundsX+150, 0, 160, 30);
 fieldValue.frame = frame;
}

[...dealloc...]

Ya see? The superclass defines the name on the left; the subclass defines the input on the right with which the user interacts. Here are the ButtonCell and SwitchCell implementations:


@implementation ButtonCell

@synthesize button;

-(id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString *)reuseIdentifier {
 [super initWithFrame:frame reuseIdentifier:reuseIdentifier];
 
 [self.contentView addSubview:fieldDisplayName];
 
 self.button = [UIButton buttonWithType:UIButtonTypeRoundedRect];
 button.backgroundColor = [self getBackgroundColor];
 button.titleLabel.textColor = [self getTextColor];
 button.titleLabel.textAlignment = UITextAlignmentLeft;
 button.titleLabel.font = [UIFont systemFontOfSize:14]; 
 [self.contentView addSubview:button];
 
 return self;
}

-(void)layoutSubviews {
 [super layoutSubviews];
 CGRect contentRect = self.contentView.bounds;
 CGFloat boundsX = contentRect.origin.x;
 CGRect frame;
 
 frame = CGRectMake(boundsX+10, 0, 140, 30);
 fieldDisplayName.frame = frame;
 
 frame = CGRectMake(boundsX+150, 0, 160, 30);
 button.frame = frame;
}

[...dealloc...]

@implementation SwitchCell

@synthesize mySwitch;

-(id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString *)reuseIdentifier {
 [super initWithFrame:frame reuseIdentifier:reuseIdentifier];
 
 [self.contentView addSubview:fieldDisplayName];
 
 self.mySwitch = [[UISwitch alloc] init];
 mySwitch.backgroundColor = [self getBackgroundColor];
 [mySwitch addTarget:self action:@selector(switchAction:) forControlEvents:UIControlEventValueChanged];
 [self.contentView addSubview:mySwitch];
 
 return self;
}

-(void)layoutSubviews {
 [super layoutSubviews];
 CGRect contentRect = self.contentView.bounds;
 CGFloat boundsX = contentRect.origin.x;
 CGRect frame;
 
 frame = CGRectMake(boundsX+10, 0, 140, 30);
 fieldDisplayName.frame = frame;
 
 frame = CGRectMake(boundsX+210, 0, 110, 30);
 mySwitch.frame = frame;
}

-(void)switchAction:(UISwitch*) sender {
 [currentController performSelector:@selector(valueChanged:) withObject: sender];
}

[...dealloc...]

Note the callbacker on the SwitchCell, not necessary on ButtonCell because we can set its target action when we create it.

There you go: a Settings architecture, and a programmatic TableViewController with a useful custom TableViewCell architecture and three examples of same. Use as you like.

And now, an actual algorithm I wrote. An algorithm! I know! Real programming! Hence my pride. The problem was, given a list of points that might have a few spurious outliers, get rid of those outliers and build a zoomed-in region that excludes them, to show in an MKMapView. My solution, in a class called Locator:


+(MKCoordinateRegion)getRegionForAnnotations:(NSArray*)annotations {

 NSMutableArray *latitudes = [NSMutableArray arrayWithCapacity:[annotations count]];
 NSMutableArray *longitudes = [NSMutableArray arrayWithCapacity:[annotations count]];

 for (id  entry in annotations) {
  double myLat = [entry coordinate].latitude;
  double myLong = [entry coordinate].longitude;
  [latitudes addObject:[NSNumber numberWithDouble:myLat]];
  [longitudes addObject:[NSNumber numberWithDouble:myLong]];
 }

 //OK, we've got the box that includes *all* the annotations
 //Now we get rid of outliers aka bad address finds.
 NSArray *sortedLatitudes = [latitudes sortedArrayUsingSelector:@selector(compare:)];
 NSArray *sortedLongitudes = [longitudes sortedArrayUsingSelector:@selector(compare:)];
 
 NSRange latLongest = [Locator getLongestContiguousRangeIn:sortedLatitudes];
 NSRange lonLongest = [Locator getLongestContiguousRangeIn:sortedLongitudes];
 
 NSNumber* minLat = [sortedLatitudes objectAtIndex:latLongest.location];
 NSNumber* maxLat = [sortedLatitudes objectAtIndex:latLongest.location+latLongest.length-1];
 NSNumber* minLon = [sortedLongitudes objectAtIndex:lonLongest.location];
 NSNumber* maxLon = [sortedLongitudes objectAtIndex:lonLongest.location+lonLongest.length-1];
 MKCoordinateRegion regionToShow = [Locator getRegionForMinLat:minLat minLong:minLon maxLat:maxLat maxLong:maxLon];
 return regionToShow;
}
  
+(NSRange) getLongestContiguousRangeIn:(NSArray*)numbers {
 NSRange longest; longest.location=0; longest.length=0;
 NSRange range; range.location=0; range.length=0;
 for (int i=0; i<[numbers count]; i++) {
  double thisLat = [[numbers objectAtIndex:i] doubleValue];
  double lastLat = i>0 ? [[numbers objectAtIndex:i-1] doubleValue] : thisLat;
  if (thisLat-lastLat<=(double)1.0)
   range.length++;
  else {
   range.location=i;
   range.length=0;
  }
  if (range.length>longest.length)
   longest=range;
 }
 return longest;
}

+(MKCoordinateRegion) getRegionForMinLat:(NSNumber*)minLat minLong:(NSNumber*)minLong maxLat:(NSNumber*)maxLat maxLong:(NSNumber*)maxLong {
  CLLocationCoordinate2D regionCenter;
  regionCenter.latitude=([minLat doubleValue]+[maxLat doubleValue])/2;
  regionCenter.longitude=([minLong doubleValue]+[maxLong doubleValue])/2;
  
  MKCoordinateSpan regionSpan;
  regionSpan.latitudeDelta=[maxLat doubleValue]-[minLat doubleValue];
  regionSpan.longitudeDelta=[maxLong doubleValue]-[minLong doubleValue];
  
  MKCoordinateRegion region;
  region.center=regionCenter;
  region.span = regionSpan;
  return region;
}

Quite elegant and efficient, if I do say so myself. It would make for an interesting interview question, too.

Weird, man, weird

2009-09-09T17:39:00.001-07:00

So I have switched to the Google Toolbox iPhone unit-test framework, and it mostly works a dream. You plug it in as per those instructions, write some tests, switch to your test target, hit "Build", and it runs your unit tests in the build phase, and highlights test failures in the same way that XCode normally highlights compile errors.

However. I have found something profoundly weird about it, which cost me a bunch of today.

Suppose your unit test is failing, and you want to debug it. Well, you can; but to do so, you have to not just Build but Run the test target, so you have to comment out the tests that are causing the build to fail. Easy enough. Then the test target launches normally in the simulator, and you can step through with the debugger, and find out what went wrong.

However. Guess what? If you leave any breakpoints in your code, and then go back and hit Build, then the Google unit-test framework will begin to fail, in strange and inexplicable ways (mostly null values where there shouldn't be any, in my case.) Remove those breakpoints - and poof, your unit tests are working again.

May you not spend a day beating your head against this, as I did.

iPhone bits and bobs

2009-09-01T09:31:00.000-07:00

Hello there, O my droogs. Long time no talk. I've been working on an iPhone app for pay, you see, which I figure kind of limits how much code I can provide you. I do have a few notes that might be worth sharing, though:

MapView code

A fully functional MapViewDelegate implementation for you. All you have to do to start putting items on maps is make them implement MKAnnotation, which is super-easy.


- (MKAnnotationView *)mapView:(MKMapView *)myMapView viewForAnnotation:(id )annotation {
 
 //this is clumsy, but there's no obvious better way - otherwise it crashes when showing user location
 if (![annotation isKindOfClass:[ECEntry class]])
  return nil;

 ECEntry *myEntry = (ECEntry*)annotation;
 
 MKPinAnnotationView *myView = (MKPinAnnotationView*)[myMapView dequeueReusableAnnotationViewWithIdentifier:@"Local"];
 if (myView==nil)
  myView = [[[MKPinAnnotationView alloc] initWithAnnotation:annotation reuseIdentifier:@"Local"] autorelease];
 myView.pinColor = myEntry.groupID==0 ? MKPinAnnotationColorGreen : MKPinAnnotationColorRed;
 myView.canShowCallout=YES;
 myView.rightCalloutAccessoryView = [UIButton buttonWithType:UIButtonTypeDetailDisclosure];
 return myView;
}

- (void)mapView:(MKMapView *)mapView annotationView:(MKAnnotationView *)view calloutAccessoryControlTapped:(UIControl *)control {
 ECEntryViewController *entryViewController = [[ECEntryViewController alloc] initWithNibName:nil bundle:nil];
 entryViewController.myEntry = (ECEntry*)[view annotation];
 [self.navigationController pushViewController:entryViewController animated:YES];
 [entryViewController release];
}

Using the camera via UIImagePickerController

So this is amazingly easy, and I can even provide you with some code that
a) launches a camera, phot-album selector, or photo-library selector, depending on what's available on your device:
b) presents the image picker as a modal view controller, keeping it within your existing NavigationController tree:
c) gets the selected/captured image (via UIImagePickerControllerDelegate) and saves it to a file.


-(void) doCamera {
 BOOL hasCamera = [UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera];
 BOOL hasAlbum = [UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeSavedPhotosAlbum];
 BOOL hasLibrary = [UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypePhotoLibrary];

 if (hasCamera || hasAlbum || hasLibrary) {
  UIImagePickerController *photoController = [[UIImagePickerController alloc] init];
  photoController.delegate = self;

  if (hasCamera)
   photoController.sourceType = UIImagePickerControllerSourceTypeCamera;
  else if (hasAlbum) {
   photoController.sourceType = UIImagePickerControllerSourceTypeSavedPhotosAlbum;
   NSString *warningMessage = [NSString localizedStringWithFormat:@"Your device has no camera, but does have an album of saved photos to choose from"];
   [Util doAlert:NSLocalizedString(@"Warning",@"Alert title") withMessage:warningMessage];
  }
  else if (hasLibrary) {
   photoController.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;
   NSString *warningMessage = [NSString localizedStringWithFormat:@"Your device has no camera, but does have a photo library to choose from"];
   [Util doAlert:NSLocalizedString(@"Warning",@"Alert title") withMessage:warningMessage];
  }
  
  [self doSave];
  [self presentModalViewController:photoController animated:YES];
  [photoController release];
 }
 else {
  NSString *alertMessage = [NSString localizedStringWithFormat:@"Your device does not support photos"];
  [Util doAlert:NSLocalizedString(@"No photo support",@"Alert title") withMessage:alertMessage];
 }
}

- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info {

 UIImage *image = [info objectForKey:UIImagePickerControllerEditedImage];
 if (image == nil)
  image = [info objectForKey:UIImagePickerControllerOriginalImage];

 //TODO, if possible: if the image has already been saved, just use its path, don't save it again

 if (image!=nil) {
  //convert image to NSData - use Settings for PNG/JPG
  [Util showActivity];
  NSData *imageData=nil;
  if ([Settings saveImagesAsPNG])
   imageData = [NSData dataWithData:UIImagePNGRepresentation(image)];
  else
   imageData = [NSData dataWithData:UIImageJPEGRepresentation(image, [Settings getJPEGQuality])];
 
  //save NSData to file
  NSString *pathDir = [Util getApplicationDocumentsPath]; 
  NSString *fileName = [[NSProcessInfo processInfo] globallyUniqueString];
  fileName = [fileName stringByAppendingString:([Settings saveImagesAsPNG] ? @".png" : @".jpg")];
  NSString *fullPath = [pathDir stringByAppendingPathComponent:fileName];

  NSError *error=nil;
  [imageData writeToFile:fullPath options:NSAtomicWrite error:&error];
  if (error) {
   NSString *errorMessage = [NSString localizedStringWithFormat:@"Unable to write to file %@: %@ - %@", fullPath, error, [error userInfo]];
   [Util doAlert:NSLocalizedString(@"Error",@"Alert title") withMessage:errorMessage];
  }
  [Util stopShowingActivity];
 
  //set entry
  myEntry.photoPath=fileName;

  //all done
  [self dismissModalViewControllerAnimated:YES];
  [self.tableView reloadData];
 }
}

- (void)imagePickerControllerDidCancel:(UIImagePickerController *)picker {
 [self dismissModalViewControllerAnimated:YES];
 [self.tableView reloadData];
}

Unit test woes
I've been having loads of trouble with the allegedly-baked-in unit-testing framework described here. Specifically, I get masses of "symbol(s) not found" linker errors when I try to compile for the Testing target, re all kinds of basic UIKit and CoreData stuff. I presume it's some kind of importing-the-wrong-kind-of-framework problem, but I have no idea how to correct it, and I don't want to dive into the seething nest of rattlesnakes that is the innards of XCode's build process. Should I just switch to the Google unit-test framework for iPhone?

down in the metal

2009-08-10T15:06:00.000-07:00

I just wanted to say that I didn't think I would ever write low-level C code again. And yet, here I am:


+(NSNumber *) getRandomDoubleMin:(double)min max:(double)max {
 srandomdev();
 int nRange = (int) max-min;
 int nRand = random() % nRange;
 double dRand = (double) nRand;
 dRand = dRand+min;
 int nRand2 = random() %10000;
 double dRand2 = (double)nRand2;
 dRand2=dRand2/10000;
 dRand=dRand+dRand2;
 return [NSNumber numberWithDouble:dRand];
}

(It's just a utility function to help populate a map with an assortment of randomly distributed pushpins, for test purposes. But still. Sheesh.)

if you love some source code, set it free

2009-08-03T19:51:00.000-07:00

So I have gone and

a) officially submitted my Wikitravel-editor iPhone app to the App Store
b) released its source code under a BSD open-source license for all to see and play with, at code.google.com/p/itravelwrite.

To be honest I would have liked another few days for cleanup and further testing, but I've gone and gotten a real job (iPhone app development, again) that will occupy me for at least a couple of months, so I had to hurry things up. I apologize for the ugliness of the code.

Some of that ugliness is due to its extremely crude testing framework. Unit testing, the panacea of modern software development, is bizarrely difficult to integrate with the iPhone SDK. There are various tools to help you - one created by Google - but they're all far more complex and kludgy than I'd like, especially compared to the elegant joy that is GAEUnit.

It turns out, however, that it is possible to seamlessly integrate unit tests and test-driven development into iPhone development with XCode. There are a few caveats, but overall, these instructions work very well, if you follow them very carefully.

The caveat is that you can only run the unit tests on an actual physical device, not in the simulator. Now, in some ways this is actually a bonus - you avoid the "but it works in the simulator!" pitfall, and I have learned that the only way to get a feel for what your UI should be is to work on a real iPhone or iPod Touch, the simulator is disastrously misleading - but it does mean that you'll have to go ahead and shell out the $100 to join the iPhone Developer Program so that you can generate the certificates needed to sign your app and install it on your device.

Which in turn is a bit of a hassle. But it's a necessary hassle, and one you should get out of the way as soon as possible. "Build early, build often," is a motto that has served me well for many years.

The device-testing is also limited in that you have to specifically select a test target, so you can't automatically run your unit tests every time you build your app. But as long as you remember to unit-test at least daily, and immediately after making major changes, I can't see this as that big a shortcoming.

Here's some code to run tests in their own separate database, so that you don't pollute your application's data.

Your test case's .h file looks something like this:


//  Dependent unit tests mean unit test code depends on an application to be injected into.
//  Setting this to 0 means the unit test code is designed to be linked into an independent executable.
#define USE_DEPENDENT_UNIT_TEST 1

#import <SenTestingKit/SenTestingKit.h>
#import <UIKit/UIKit.h>
#import "MyAppDelegate.h"


@interface MyTestCase : SenTestCase {
    NSManagedObjectContext *context;
}

@end

and its .m:


-(void) setUp {
    MyAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];
    NSURL *storeUrl = [NSURL fileURLWithPath: [[appDelegate applicationDocumentsDirectory] stringByAppendingPathComponent: @"MyAppTest.sqlite"]];

 NSError *error;
    NSPersistentStoreCoordinator *persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: [appDelegate managedObjectModel]];
    if (![persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeUrl options:nil error:&error]) {
        // Handle error
  NSLog(@"Error creating persistent store MyAppTest.sqlite %@, %@", error, [error userInfo]);
    }
 context = [[NSManagedObjectContext alloc] init];
 [context setPersistentStoreCoordinator: persistentStoreCoordinator]; 
}

-(void) tearDown {
 [context release];
}

HttpHelper

2009-07-17T19:24:00.000-07:00

...it's sort of like Hamburger Helper, only tastier.

It's been a week of tweaking, fixing little bugs, spiralling in towards hoped-for perfection. I'm pleased to report that I now have an alpha-test version of my iPhone app up and running on my iPod Touch, and it looks to work a charm. If all goes very well indeed I might submit it to the App Store - where it will ultimately be available for the low low price of $0.00 - by the end of the month.

In the meantime, here's a utility class that people might find handy: my HttpHelper singleton. It's not really a class variable, since it seems Objective-C doesn't support them (Oh, Smalltalk, how I miss your class instance variables) but "static" has the same effect, if you code carefully. Like so:


//
//  HttpHelper.m
//  iTravelWrite
//
//  Singleton class used to send HTTP requests and forward responses to selectors passed in by the caller.
//  Created by Jon Evans on 04/07/09.
//

#import "HttpHelper.h"
#import "Util.h"

@implementation HttpHelper

static HttpHelper *singleton=nil;

#pragma mark -
#pragma mark Singleton methods

+(HttpHelper *) getInstance {
 if (singleton==nil)
  singleton = [[HttpHelper alloc] init];
 return singleton;
}

+(id)allocWithZone:(NSZone *)zone {
 if (singleton == nil) {
  singleton = [super allocWithZone:zone];
  return singleton;
 }
 return nil;
}

-(id)copyWithZone:(NSZone *)zone {
 return self;
}

-(id)retain {
 return self;
}

-(unsigned)retainCount {
 return UINT_MAX;
}

-(void)release {
 //pass
}

-(id)autorelease {
 return self;
}

- (void)dealloc {
    [super dealloc];
}

All the above is housekeeping stuff to ensure that we only ever have one instance of an HttpHelper. Not that a duplicate would be so disastrous in this case, but hey, if you're writing a singleton, write a singleton, right?

Here's the part where it actually does stuff. In particular, it does all the HTTP GETs and HTTP POSTs that your iPhone app will ever need:


#pragma mark -
#pragma mark Business logic

+(NSURLRequest*) buildRequestWithPostKeys:(NSArray *) postKeys postValues:(NSArray *) postValues urlString:(NSString *)urlString {
 
 NSMutableString *params=[[NSMutableString alloc] initWithCapacity:1024];
 for (int i=0; i<[postValues count]; i++) {
  [params appendString:[postKeys objectAtIndex:i]];
  [params appendString:@"="];
  [params appendString:[postValues objectAtIndex:i]];
  [params appendString:@"&"];
 }
 NSData * paramData = [params dataUsingEncoding:NSUTF8StringEncoding];
 
 NSURL * url = [NSURL URLWithString:urlString];
 NSURLRequestCachePolicy policy = NSURLRequestReloadIgnoringCacheData; // never cache a post response, at least in my app
 NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:policy timeoutInterval:10.0];
 
 NSString *msgLength = [NSString stringWithFormat:@"%d", [paramData length]];
 [request addValue: msgLength forHTTPHeaderField:@"Content-Length"];
 [request setHTTPMethod:@"POST"];
 [request setHTTPBody: paramData];
 return request;
}

+(BOOL) doPost:(NSURLRequest *)request forCaller:(id)caller onSuccess:(SEL)onSuccess onFailure:(SEL)onFailure {
 
 NSArray *keys = [NSArray arrayWithObjects:@"request", @"caller", @"onSuccess", @"onFailure", nil];
 NSArray *values = [NSArray arrayWithObjects:request, caller,
        [NSValue valueWithBytes:&onSuccess objCType:@encode(SEL)],
        [NSValue valueWithBytes:&onFailure objCType:@encode(SEL)],
        nil];
 NSDictionary *args = [NSDictionary dictionaryWithObjects:values forKeys: keys];
 NSThread* uploadThread = [[NSThread alloc] initWithTarget:[self getInstance] selector:@selector(doHttp:) object:args];
 [uploadThread start];
 [uploadThread release];
 return TRUE;
}

+(NSURLRequestCachePolicy)getCachePolicyFor:(NSString *)urlString {
 /*
  Hived out to a separate method because we might fine-tune this later.
  
  In theory, this will cause the app to use the cache policies set by
  wetravelwrite.appspot.com, which as of this writing means 1 hour
  for listing information, and 10 hours for searches.
  
  In the ListingEditController and ListingsViewController we manually wipe
  the cache for listings edited by the app.
 */
// return NSURLRequestUseProtocolCachePolicy;
 return NSURLRequestReloadIgnoringCacheData;
}

+(NSURLRequest *)getURLRequestFor:(NSString *)urlString {
 NSURL *url = [NSURL URLWithString:urlString];
 NSURLRequestCachePolicy policy = [self getCachePolicyFor:urlString];
 NSURLRequest *request = [NSURLRequest requestWithURL:url cachePolicy:policy timeoutInterval:7.5];
 return request;
}

+(BOOL) doGet:(NSString *)urlString forCaller:(id)caller onSuccess:(SEL)onSuccess onFailure:(SEL)onFailure {
 NSURLRequest *request = [self getURLRequestFor:urlString];
 NSArray *keys = [NSArray arrayWithObjects:@"request", @"caller", @"onSuccess", @"onFailure", nil];
 NSArray *values = [NSArray arrayWithObjects:request, caller,
        [NSValue valueWithBytes:&onSuccess objCType:@encode(SEL)],
        [NSValue valueWithBytes:&onFailure objCType:@encode(SEL)],
        nil];
 NSDictionary *args = [NSDictionary dictionaryWithObjects:values forKeys: keys];
 NSThread* uploadThread = [[NSThread alloc] initWithTarget:[self getInstance] selector:@selector(doHttp:) object:args];
 [uploadThread start];
 [uploadThread release];
 return TRUE;
}

-(BOOL) doHttp:(NSDictionary *)args
 {
 @synchronized (self) {
  //autorelease pool
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  
  NSURLRequest *request = [args objectForKey:@"request"];
  NSObject *caller = [args objectForKey:@"caller"];
   
  SEL onSuccess;
  [[args objectForKey:@"onSuccess"] getValue:&onSuccess];
  SEL onFailure;
  [[args objectForKey:@"onFailure"] getValue:&onFailure];
   
  NSError *error;
  NSData *returnData = [NSURLConnection sendSynchronousRequest: request returningResponse: nil error: &error ];
  NSString * responseString = [[NSString alloc] initWithData: returnData encoding: NSASCIIStringEncoding];
   
  if (!error) //connection succeeded; but did it work?
   error = [Util getErrorFrom:responseString forRequest:request];
   
  if (error) {
   NSLog(@"iTravelWrite Error ",error);
   [caller performSelectorOnMainThread: onFailure withObject:error waitUntilDone:NO];
  }
  else
   [caller performSelectorOnMainThread: onSuccess withObject:responseString waitUntilDone:NO];
  [pool release];
 }
 return TRUE;
}

@end

Pretty slick, huh?

The three chief interface methods are, for a GET -


+(BOOL) doGet:(NSString *)urlString forCaller:(id)caller onSuccess:(SEL)onSuccess onFailure:(SEL)onFailure

and for a POST -


+(NSURLRequest*) buildRequestWithPostKeys:(NSArray *) postKeys postValues:(NSArray *) postValues urlString:(NSString *)urlString

+(BOOL) doPost:(NSURLRequest *)request forCaller:(id)caller onSuccess:(SEL)onSuccess onFailure:(SEL)onFailure {

I'll give you an example of the former first, as it's easier. The call itself is perfectly straightforward:


 NSMutableString *urlString = [NSMutableString stringWithCapacity:128];
 [urlString appendString:[Util getSearchPageURL]];
 [urlString appendString:@"?locale="];
 [urlString appendString:[UserSettings getLanguage]];
 [urlString appendString:@"&searchTerms="];
 [urlString appendString:[searchBar.text stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
 [HttpHelper doGet:urlString forCaller:self onSuccess:@selector(parseSearchResults:) onFailure:@selector(searchFailed:)];

Not, however, the two "@selector" arguments. These must be methods on the caller, and they better expect an NSString* and an NSError*, respectively, as arguments. (Or they can take an NSObject* and cast from there, I suppose, but why bother, right?)

Inside HttpHelper we have to wrap the selectors in NSValues to pass them from method to method, which is a bit annoying, but hey, we only have to do it once.

To call a POST, by comparison:


 NSArray *postKeys = [NSArray arrayWithObjects:@"title", @"location", @"comments", @"pageUri", @"sectionName", @"sectionNumber", @"listingName", nil];
 NSArray *postValues = [NSArray arrayWithObjects:note.title, [note locationString], note.body, note.pageUri, note.sectionName, note.sectionNumber, note.listingName, nil];
 NSURLRequest *request = [HttpHelper buildRequestWithPostKeys:postKeys postValues:postValues urlString:[Util getUploadNoteURL]];
 [HttpHelper doPost:request forCaller:self onSuccess:@selector(onUploadSuccess) onFailure:@selector(onUploadError:)];

Note that "onUploadSuccess" here doesn't take an argument - I don't care about the web site's response, the fact of success is all that matters. OK, dubious wisdom that, but the example is relevant to show that the selector methods don't actually have to accept arguments.

We launch a new thread every time we call HttpHelper, so we have to be careful lest we run into concurrency problems. So we synchronize the actual HTTP calls in the "doHttp:" method, which is the one place in the app where we actually go out and connect to the big bad scary Internet.

Note also that if we wanted to change from using "sendSynchronousRequest:" to the delegated version of NSURLConnection, the only class that would change is HttpHelper. Ah, encapsulation.

Anyway. Share and enjoy, as the man said. Hope all that's useful to someone out there...

Step right up to view the fabulous ListingViewController!

2009-07-06T19:19:00.000-07:00

Tickets ~~$25~~ $5 $1 OK, fine, free.

I have had a highly productive day with the iPhone SDK and now I am going to inflict it on you too. Specifically, I am going to show you the complete annotated code for the ListingViewController, the view controller which, despite its less than thrilling name, is kind of the heart of my iPhone application.

Ready? Buckle your seat belts. It's gonna be a bumpy post.

Here goes nothing: here's the header file -


//
//  ListingsViewController.h
//  iTravelWrite
//
//  Created by Jon Evans on 02/07/09.
//

#import 
#import 
#import "PageSearchResult.h"
#import "ViewEntry.h"

@interface ListingsViewController : UITableViewController  {
 NSManagedObjectContext *managedObjectContext;     
        CLLocationManager *locationManager;
 PageSearchResult *page;
 ViewEntry *rootEntry;
        UIBarButtonItem *addNoteButton;
 UIBarButtonItem *editListingButton;
 UIBarButtonItem *iAmThereButton;
 BOOL createdRoot;
}
-(void)addNote;
-(void)editListing;
-(void)iAmThere;

@property (nonatomic, retain) NSManagedObjectContext *managedObjectContext;
@property (nonatomic, retain) CLLocationManager *locationManager;
@property (nonatomic, retain) PageSearchResult *page;
@property (nonatomic, retain) ViewEntry *rootEntry;
@property (nonatomic, retain) UIBarButtonItem *addNoteButton;
@property (nonatomic, retain) UIBarButtonItem *editListingButton;
@property (nonatomic, retain) UIBarButtonItem *iAmThereButton;

@end

Lots of stuff there, most of it self-explanatory. A few bits you won't recognize:

"PageSearchResult" comes from the previous view in the hierarchy, in which the user searches WikiTravel (or selects from previously used pages), and contains the name and URL of the page that the user wishes to edit.

"ViewEntry" is a horrifically generic name and I should probably rename it to "WikiTravelEntry" or something like it. See, WikiTravel pages have intrinsic hierarchies. The "Toronto" page, for instance, has sections like "Districts" and "Eat", which in turn have subsections like "Islands" and "Farmer's Markets". Meanwhile, individual listings - like "Royal Ontario Museum" and "Yumi Japanese Restaurant" - can be attached to any section at all.

Too complicated? Let me give you an analogy. You've got your iPod, right? Well, under the "Music" heading, you can have a list of Artists; each Artist can have a list of Albums; and individual Songs can appear under Music, Artist, or Album.

Think of a WikiTravel listing as a Song, and a WikiTravel section as a folder. Well, a ViewEntry can represent either a Section or an individual Listing; and if it's a Section, then it can have children, and they too can be Sections or Listings.

Huh. So WikiTravel is basically laid out in the same way as an iPod's music. Hey, does that mean the iPhone SDK, with its seamless hierarchy-navigation UI tools, is totally perfect for a WikiTravel iPhone app?

Dude. Does it ever. Check it out:


//
//  ListingsViewController.m
//  iTravelWrite
//
//  Created by Jon Evans on 02/07/09.
//

#import "ListingsViewController.h"
#import "NoteEditController.h"
#import "ListingEditController.h"
#import "HttpHelper.h"
#import "Util.h"
#import "Note.h"

@implementation ListingsViewController

@synthesize managedObjectContext, locationManager, page, rootEntry, addNoteButton, editListingButton, iAmThereButton;

- (void)viewDidLoad {
    [super viewDidLoad];
 
 //nav bar
 //TODO: localize this string, and those below
 self.navigationItem.title=@"Loading...";
 
 //location manager
 [[self locationManager] startUpdatingLocation];

 //toolbar
 self.iAmThereButton = [[UIBarButtonItem alloc] initWithTitle:@"I'm There!" style:UIBarButtonItemStyleBordered
                   target:self action:@selector(iAmThere)]; 
 iAmThereButton.enabled=NO;
 self.addNoteButton = [[UIBarButtonItem alloc] initWithTitle:@"Note To Self" style:UIBarButtonItemStyleBordered
                   target:self action:@selector(addNote)];
 addNoteButton.enabled=NO;
 self.editListingButton = [[UIBarButtonItem alloc] initWithTitle:@"Edit Listing" style:UIBarButtonItemStyleBordered
                  target:self action:@selector(editListing)]; 
 editListingButton.enabled=NO;

 self.toolbarItems = [NSArray arrayWithObjects:iAmThereButton, addNoteButton, editListingButton, nil];
 [self.navigationController setToolbarHidden:NO];

 //activity button
 UIActivityIndicatorView *loading = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhite];
 loading.frame=CGRectMake(0.0, 0.0, 25.0, 25.0);
 [loading sizeToFit];
 loading.autoresizingMask = (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight);
 UIBarButtonItem *activityButton = [[UIBarButtonItem alloc] initWithCustomView:loading];
 self.navigationItem.rightBarButtonItem = activityButton;
 [loading release];
 [activityButton release];
}

This is pretty basic stuff: assign text and buttons to the navigation bar and toolbar you get for free by subclassing UITableViewController.

Perhaps most interesting is the bit at the end, where I assign a UIActivityIndicatorView - that little swirly "something is happening" animated wheel - to a custom UIBarButton. Such a beast is invisible until you tell it "startAnimating". Which we do next, which is when things get interesting -


//Fill the table
- (void)viewDidAppear:(BOOL)animated
{
 UIActivityIndicatorView *loading = (UIActivityIndicatorView*) self.navigationItem.rightBarButtonItem.customView;
 if (!rootEntry) { //only load for the top of the hierarchy
  [loading startAnimating];
  NSThread* loadThread = [[NSThread alloc] initWithTarget:self selector:@selector(loadViewEntries) object:nil];
  [loadThread start];
  [loadThread release];
  createdRoot = YES;
 }
 else
 {
  createdRoot = NO;
  self.navigationItem.title=rootEntry.sectionName;
  [self.tableView reloadData];
 }
}

So. First, you may be wondering, "why is this in viewDidAppear rather than viewDidLoad?" The main reason is that it can take a while to load the data, and I don't want the app to freeze up completely for a few seconds.

Now, if "rootEntry" is nil, that means we have to go out to the Internet and get our data. But wait! If we were to go load this view's contents from the Internet in the same thread, the UI would block. If we want to feign responsiveness, and reassure the user that something is indeed happening with the UIActivityIndicatorView swirly, then we have to launch a new background thread. Which we do.

The whole "createdRoot" thing is really kind of ugly, but necessary to avoid deallocation disaster. If it's any kind of consolation, it's only ever used in dealloc.

So. Our new thread goes and calls the "loadViewEntries" selector. Note that we didn't even define "loadViewEntries" in the header file, but selectors work at run-time, so it doesn't matter. It's almost like the Smalltalk "perform:" notation. Which is kinda awesome. Oh, Objective-C, I love you, when I don't hate you.

So our thread reaches out and calls:


-(void)loadViewEntries
{
 //autorelease pool
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 
 //load listings
 NSString *urlRoot = [[Util getListingsURL] stringByAppendingString:@"?page="];
 NSString *urlString = [urlRoot stringByAppendingString:[page.urlSuffix stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
 NSURL *url = [NSURL URLWithString:urlString];
 NSURLRequest *request = [NSURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:10.0];
 NSData *returnData = [NSURLConnection sendSynchronousRequest: request returningResponse: nil error: nil ];
 NSString * responseString = [[NSString alloc] initWithData: returnData encoding: NSASCIIStringEncoding];
 // [Util doAlert:@"Response" withMessage:responseString];
 
 //parse listings
 self.rootEntry = [[ViewEntry alloc] initWithValueString:responseString levelsFromTop:0];
 rootEntry.sectionName=page.pageName;
 [self performSelectorOnMainThread: @selector(loadFinished) withObject:nil waitUntilDone:NO];
 [pool release];
}

Two key things to note here. One is that we create an autorelease pool at the beginning of this method, and release it at the end. You have to do this whenever you create a new thread, or you face major memory leakage. What a hassle, and what a disaster if you forget. Oh, Objective-C, I hate you when I don't love you.

Next - and this is important - you cannot call UIKit, which in this context basically means anything to do with any view, from inside your new spawned thread. If you do, your app will die with "Tried to obtain the web lock with a thread other than the main thread or the web thread. This may be a result of calling to UIKit from a secondary thread." Oh, Objective-C, I hate you etc.

(Also: web thread? Where can I get me a piece of that?)

At least they give you a fairly easy way around it: the "performSelectorOnMainThread: withObject: waitUntilDone:" method on NSObject. Which works just fine, but means you have to create yet another method to do whatever you want done when the thread completes:


-(void)loadFinished
{
 UIActivityIndicatorView *loading = (UIActivityIndicatorView*) self.navigationItem.rightBarButtonItem.customView;
 self.navigationItem.title=rootEntry.sectionName;
 [loading stopAnimating];
 [self.tableView reloadData];
}

OK. So we've populated our hierarchy of data (which happens offscreen in ViewEntry's "init" method.) Now what are we going to do with it?


#pragma mark -
#pragma mark TableView

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return [[rootEntry getChildren] count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
 static NSString *CellIdentifier = @"ViewEntryCell";
 
 UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
 if (cell == nil)
  cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
 
 // Set up the cell...
 ViewEntry *entry = [[rootEntry getChildren] objectAtIndex:indexPath.row]; 
 cell.textLabel.text = [entry getName];
 if ([entry hasChildren])
  cell.accessoryType=UITableViewCellAccessoryDisclosureIndicator;
 else
  cell.accessoryType=UITableViewCellAccessoryNone;
 
 return cell;
}

And that's all you need to do to show the data to the user. Pretty slick, eh? Did I mention that this entire view is created programmatically, with no nib file? Did you notice I never actually created or laid out a view? If your app fits into a hierarchy of TableViews, and fortunately mine fits perfectly, the iPhone SDK is really a dream to work with.

So we show the user the current section's children, which can be subsections or listings (think albums or songs). If the former, we show a little chevron which means you can drill down the hierarchy further. And when the user selects...


- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
 ViewEntry *selectedEntry = [[rootEntry getChildren] objectAtIndex:indexPath.row];
 if ([selectedEntry hasChildren]) {
  //push this subsection onto the stack
  ListingsViewController *lvController = [[ListingsViewController alloc] initWithNibName:nil bundle:nil];
  lvController.managedObjectContext = self.managedObjectContext;
  lvController.locationManager = self.locationManager;
  lvController.page = self.page;
  lvController.rootEntry = selectedEntry;
  [self.navigationController pushViewController:lvController animated:YES];
  [lvController release];
 }
 else {
  addNoteButton.enabled=YES;
  editListingButton.enabled=YES;
  if ([locationManager location])
   iAmThereButton.enabled=YES;
 }
}

...we either create a new instance of this very same controller, pass the relevant data to it, and push it onto the view stack; or, if it's a listing (eg "Royal Ontario Museum"), we enable the three do-something-with-a-listing buttons in the toolbar.

Yes, that's right, that's all the code we need to navigate an arbitrarily sized view hierarchy by creating a tree of ListingViewControllers on the fly and stacking them atop one another. The SDK handles navigation and so forth for us. Cool, eh?

What do those buttons do? Well...


#pragma mark -
#pragma mark Business logic

-(void) addNote {
 NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow];
 ViewEntry *listing = [[rootEntry getChildren] objectAtIndex:indexPath.row];
 Note *newNote = (Note *)[NSEntityDescription insertNewObjectForEntityForName:@"Note" inManagedObjectContext:managedObjectContext];
 
 // Configure the new note
 [newNote setIsUploaded:[NSNumber numberWithBool:FALSE]];
 [newNote setCreationDate:[NSDate date]];
 [newNote setUserEmail:[Util getEmail]];
 [newNote setSectionName:[listing sectionName]];
 [newNote setSectionNumber:[listing sectionNumber]];
 [newNote setListingName:[listing listingName]];
 [newNote setPageUri:[page urlSuffix]];
 CLLocation *location = [locationManager location];
 if (location) {
  CLLocationCoordinate2D coordinate = [location coordinate];
  [newNote setLatitude:[NSNumber numberWithDouble:coordinate.latitude]];
  [newNote setLongitude:[NSNumber numberWithDouble:coordinate.longitude]];
 }
 
 NoteEditController *noteEditController = [NoteEditController alloc];
 noteEditController.note = newNote;
 [self.navigationController pushViewController:noteEditController animated:YES];
 [noteEditController release];
}

Here you get to see a) part of the Core Data persistence layer in action, b) the LocationManager where-am-I code in action, and c) the creation of a new kind of detail-view controller.

a) We get the ManagedObjectContext from our parent ViewController, who in turn got it from the RootViewController, who in turn got it from the AppDelegate. There are times - such as when you want to save one object, but not another - when you might want more than one ManagedObjectContext, but I haven't bumped into them yet. I think I might be able to get it from the AppDelegate which serves as something of a global, but for now I'm passing them from ViewController to ViewController.

And yeah, "Note" is a horribly generic name. I oughta rename it to "TravelNote" or something. The idea is that, rather than deal with the detailed listing-edit screen, you can jot a few words where you are, and upload that Note to wetravelwrite.com. Then, later,you'll get an email reminder (if you've opted for them) complete with a link, so that when you're at a computer with a real keyboard and screen, you can go online and edit that lasting as per your note and location.

b) We construct the LocationManager in a method further below.

c) OK, so it's not that exciting.


-(void)editListing{
 NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow];
 ViewEntry *listing = [[rootEntry getChildren] objectAtIndex:indexPath.row];

 ListingEditController *listingEditController = [ListingEditController alloc];
 listingEditController.listingData = [listing listingData];
 NSArray *keys = [NSArray arrayWithObjects:@"oldName", @"sectionToEdit", @"sectionNumber", @"editPageUrl", nil];
 NSArray *values = [NSArray arrayWithObjects:[listing listingName], [listing sectionName], [listing sectionNumber],  [page urlSuffix], nil];
 NSDictionary *listingMetaData = [NSDictionary dictionaryWithObjects:values forKeys: keys];
 listingEditController.listingMetadata = listingMetaData;

 [self.navigationController pushViewController:listingEditController animated:YES];
 [listingEditController release];
}

Pretty much the same thing, only messier. That's a lot of crap passing between ViewControllers, and I'd be tempted to abstract it into an object if this happened anywhere else; fortunately, it doesn't. And the crap is necessary, alas. The detail controller includes seventeen fields. Yes, seventeen. Which is probably OK if you're just tweaking a few details of an existing listing, but is also the reason I added the note-to-future-self functionality. I am going to add an "Add New Listing" button, but I don't expect too many people to use it.


-(void)iAmThere{
 NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow];
 ViewEntry *listing = [[rootEntry getChildren] objectAtIndex:indexPath.row];

 //construct location string
 CLLocation *location = [locationManager location];
 CLLocationCoordinate2D coordinate = [location coordinate];
 NSString *locationString = [[NSNumber numberWithDouble:coordinate.latitude] stringValue];
 locationString = [locationString stringByAppendingString:@","];
 locationString = [locationString stringByAppendingString:[[NSNumber numberWithDouble:coordinate.longitude] stringValue]];

 //build http request
 NSArray *postKeys = [NSArray arrayWithObjects:@"pageUri", @"sectionName", @"sectionNumber", @"listingName", @"location", nil];
 NSArray *postValues = [NSArray arrayWithObjects:[page urlSuffix], listing.sectionName, listing.sectionNumber, listing.listingName, locationString, nil];
 HttpHelper *http = [[HttpHelper alloc] initWithPostKeys:postKeys postValues:postValues urlString:[Util getLocationUpdateURL]];
 NSURLRequest *request = [http request];

 //create connection
 NSURLConnection *theConnection = [NSURLConnection connectionWithRequest:request delegate: self];
 if (!theConnection) {
  // inform the user that the download could not be performed
  // TODO: real error handling
  [Util doAlert:@"Connection creation failure" withMessage:@"Connection failed"];
 }
 [http release];
}

- (void)connection:(NSURLConnection *)connection
  didFailWithError:(NSError *)error
{
    // release the connection, and inform the user
 [Util handleError:@"Connection Failure" withError: error];
}

- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
 //TODO: add checkbox indicating listing located
 [Util doAlert:@"Success" withMessage:@"Connection finished"];
}

Here we have an HTTP connection. The idea being that people can geotag WikiTravel listings with one button; you're passing by the Royal Ontario Museum, you check your iPhone app, you notice that it does not yet have a geotag (I haven't yet, but will, added checkboxes to indicate this), and you push the "I'm there!" button to update its WikiTravel listing with your current location, no typing necessary.

Now, you can perform an HTTP request in a single line, with NSURLConnection's sendSynchronousRequest: method, but this one uses delegation, so we implement the "connectionDidFail..." and "connectionDidFinish" methods.

HttpHelper is my own class, used to give me a central point of control over all HttpRequests, partly so I didn't have to keep copy-pasting code, partly so I can handle caching in one place. (Although I think I may have to add a new "keep or clear cache" to its init.) Util is my own class that holds basic fixed values and utility methods.


#pragma mark -
#pragma mark Location manager
/**
 Return a location manager -- create one if necessary.
 */
- (CLLocationManager *)locationManager {
 
    if (locationManager != nil) {
  return locationManager;
 }
 
 self.locationManager = [[CLLocationManager alloc] init];
 [locationManager setDesiredAccuracy:kCLLocationAccuracyNearestTenMeters];
 [locationManager setDelegate:self];
 
 return locationManager;
}


/**
 Conditionally enable the Add button:
 If the location manager is generating updates, then enable the button;
 If the location manager is failing, then disable the button.
 */
- (void)locationManager:(CLLocationManager *)manager
    didUpdateToLocation:(CLLocation *)newLocation
           fromLocation:(CLLocation *)oldLocation {
 if ([[self tableView] indexPathForSelectedRow]) {
  iAmThereButton.enabled = YES;
 }
}

- (void)locationManager:(CLLocationManager *)manager
       didFailWithError:(NSError *)error {
    iAmThereButton.enabled = NO;
}

And that's how you use the location manager; like much of the iPhone SDK, it's a delegate pattern. You create it and set its delegate; it goes out and tries to work out where you are; when it succeeds or fails, it lets you know. Simple, really.


#pragma mark -
#pragma mark Cleanup

- (void)dealloc {
 [addNoteButton release];
 [editListingButton release];
 [iAmThereButton release];
 if (createdRoot) {
  [rootEntry release];
  [locationManager release];
 }
    [super dealloc];
}

@end

Note that we only release the rootEntry and locationManager if we're the king ViewController at the top of the hierarchy. Otherwise we're asking for serious EXC_BAD_ACCESS disaster.

Aaaaaand there you go. The whole ListingViewController, in all its glory.

Note, he mentioned with some pride, that I started it writing it only four days ago - and that it's only maybe a quarter of the code I've written and tested since then.

One last caveat. You'll notice there's no copyright claim up above, and you're welcome to use the code as is, but - while it's pretty much running now, there are still tweaks I want to make. Error handling and localization, in particular. And I have hardly any unit tests yet. So if your need isn't dire and urgent, I advise you to wait until I officially release the code at code.google.com, under an open-source license, and post to this blog to that effect.

Don't call me an Objectivist...

2009-07-02T19:47:00.000-07:00

...but I speak a new language now.

Well, sorta. I write to you on my shiny new MacBook, which I purchased in part because you can't write iPhone applications on non-Macs. I guess I don't resent that. Much. It is a nice machine, although I'm still getting used to all of OS X's quirks.

But never mind the OS: writing an iPhone version of my app means mastering the iPhone SDK and a whole new language, Objective-C. Which was kind of frustrating for a week. Imagine, for a moment, that you're a car mechanic. Now imagine that you move to a new garage, where the cars are totally different, not just the engines but even the doors and the dashboard controls are laid out in some bizarre new arrangement, and instead of your old tools, there's a wall full of all these curvy New Age things that look more like vacuum cleaner parts and art objects than hex wrenches and hammers. That's kind of what diving into the iPhone SDK was like.

But. You are a car mechanic. And ultimately, we're still talking about wheeled vehicles powered by internal combustion engines; so after a bewildering week, during which you often don't even know what questions to ask, you begin to realize that in fact these cars are quite elegantly if counterintuitively designed, and that these tools are well suited to them.

Yeah, so the metaphor got out of hand, sue me. Anyway, I didn't know Objective-C, but I've been writing software professionally for nigh on twenty years now, and it's kind of a weird mixture of C and Smalltalk, both of which I have worked with before. It turns out that it is a powerful and flexible language, and the iPhone SDK's tools and libraries do indeed ultimately make sense.

Don't get me wrong. There are still things I hate. Mostly the hangovers from C. Just like C, object you create requires two files: one where all the code goes, and a "header file" that describes the code. It was a bad idea then, and it's a bad idea now, which is why no modern languages require it. The resulting profusion of files is messy, annoying, completely unnecessary, and provides more places for things to go wrong.

Also, you have to allocate memory by hand, and then be extremely careful to de-allocate it, lest you leak memory and consume all your phone's resources. I shake my head with bewildered contempt. Manual memory management is archaic, clumsy, tedious, and perpetually prone to disaster. Making it part of the iPhone SDK is like having a beautifully renovated marble-and-gold bathroom built atop lead plumbing.

(My understanding is that if you're writing for Macs, you can have automatic garbage collection, like the rest of the civilized world, but such is strongly discouraged on the iPhone. Scarce resources, apparently. But I note that Java development for similarly specced Android phones, with garbage collection - and sans useless header files - works just fine...)

I have also learned that there are subtle pitfalls in the Objective-C environment. I'll concede that this can be true of Java as well, though usually that's when you're dealing with classpaths, less of an issue when doing Android development. But, well, see for yourself. Here's what looks like a garden-variety call to a Settings class:


 NSMutableString *urlString = [NSMutableString stringWithCapacity:128];
 [urlString appendString:[Settings getSearchPageURL]];

which should call the "getSearchPageURL" class method on my "Settings" class, which right now is pretty much just a bundle of constants. Here's a simplified Settings.h:


#import <UIKit/UIKit.h>

@interface Settings {
}
+(NSString *) getSearchPageURL;

and Settings.m:


+(NSString *)getSearchPageURL
{
 return @"http://wetravelwrite.appspot.com/mb/searchForPage";
}

Nothing to it, right? Compiled just fine. Did it run? Did it hell. Instead I got


2009-07-02 22:48:28.519 iTravelWrite[17002:20b] *** NSInvocation: warning: object 0xaa40 of class 'Settings' does not implement methodSignatureForSelector: -- trouble ahead
2009-07-02 22:48:28.520 iTravelWrite[17002:20b] *** NSInvocation: warning: object 0xaa40 of class 'Settings' does not implement doesNotRecognizeSelector: -- abort

OK, points for the amusing "trouble ahead" warning, but what the hell? I'm just calling a very simple function that does nothing but return a hardcoded string - so what could possibly have gone wrong?

Turns out that function automatically gets abstracted up at runtime into a selector - and for that to work, Settings must extend NSObject. Which is trivially done, of course, but far from intuitive.

Wacko problem number 2: I changed a variable from an NSArray to an NSDictionary, and reworked the code appropriately - no big deal - and suddenly the app was dying with an EXC_BAD_ACCESS call, meaning that I was trying to release the memory of an object I had already released. Muttering foul imprecations about the whole notion of manual garbage collection, I went carefully through my code and found ... nothing. So I Googled. (Which is how I ultimately solved the previous problem, too; but in both cases I had to go well past the first page of results, which is one reason I'm writing this with copious details. Maybe future sufferers will find their way to this post.)

Here are the relevant parts of the header file:


@interface SearchController : UITableViewController  {
 NSDictionary *searchResults;
}
@property (nonatomic, retain) NSDictionary *searchResults;

and it turns out that the problematic line in the implementation was this one:


searchResults = [NSDictionary dictionaryWithObjects: urlSuffixes forKeys: pageNames];

Looks harmless enough, doesn't it? Both urlSuffixes and pageNames are perfectly acceptable NSArrays of NSStrings. So what's the problem?

Well, if you're not familiar with Objective-C, you might be a little gobsmacked to learn that the solution was to change the above line to


self.searchResults = [NSDictionary dictionaryWithObjects: urlSuffixes forKeys: pageNames];

Yes, really.

As far as I can tell, the difference is that in the second example, instead of the instance variable being directly modified, the @synthesized auto-generated setter is called, with "retain" as dictated in the @property definition, which prevents the NSDictionary from being released when we exit the method which generates it. Perhaps some people think of this stuff as intuitive. Not me. It's all fixed and working now, but this kind of man-behind-the-curtain stuff makes me a little uneasy.

That said, there's a lot to like. The user-interface stuff, once you figure it out, is (mostly) a joy to work with. You can lay out items visually or programmatically; you get a built-in navigation header and button toolbar, yours for just a few lines of code; it's easy to reach out via HTTP, with a one-line synchronous-call version, a delegated version with fine control, or a compromise somewhere between; and as of the 3.0 SDK, instead of hand-writing SQL code to access SQLite, you can use Apple's Core Data engine to manage all your persistent data. (Which comes with its own problems but overall is definitely more elegant and more powerful.)

Also, while I wouldn't say that I'm fluent in Objective-C yet, I'm now conversant, and I like it a lot when it's reminding me of Smalltalk, and not reminding me of C. You do, however, seem to wind up writing a lot more lines of code than you would in Java to do the same thing. It's like speaking German vs. English.

Overall, though, qualified thumbs up. I still prefer Java to Objective-C, and there are still things that Android can do and the iPhone can't - multitasking is the biggest, and the associated inter-app communication possibilities - while I can't think of any examples of the converse. But I am increasingly a fan of the latter's SDK. What at first looked a bit like a junkyard is now becoming more of a playground.

I am the alpha dog!

2009-06-17T20:50:00.000-07:00

By which I mean, my Android app is now in alpha test: I just uploaded it onto my HTC Magic, and whaddaya know, it runs, it doesn't crash, it actually does stuff. Indeed, I just updated WikiTravel via its interface. (Slightly buggily, but hey, alpha test.)

Mind you, the Android app is a fairly trivial piece of programming next to the AppEngine middleware that does the actual parsing and updating of WikiTravel. Which is the way it should be. Resources are scarce on a smartphone, and both processing and battery power are relatively meagre; I expect the design pattern of choice is going to be "get as much of the work done as you can on your server farm, then communicate simple low-bandwidth stuff to the phone."

Ultimately, the phone isn't much more than a user interface. In fact, now that I think about it, my whole app follows the classic Model-View-Controller design: WikiTravel is the model, the smartphone is the view, and my AppEngine service is the controller. Huh. Plus ça change, plus c'est la même chose.

Anyway, a list of tips, tricks, and annoyances since last we met:

Let's start off with the annoyances. Character encoding. This has never been my strong suit, and I all too often wind up trial-and-erroring a solution. What doesn't help here is that I've got URL encoding (eg "?"->"%3F" in an HTTP request), HTML encoding (eg & -> & in a web page) and actual character encoding (ASCII? Unicode? UTF-8?) and while I grok the first two, I always have a mental block with the latter. I seem to have brute-forced something like a solution. We'll see. I expect it will rear its ugly head again.

Python, weirdly, for all its text-processing power, doesn't come with much in the way of built-in HTML escaping and unescaping. "cgi.escape" will do much, but, annoyingly, not everything in the way of escaping. As for unescaping, fuhgedaboudit. Fortunately, I found this neat little solution somewhere on the Internets:
```
#HTML unescape
#taken from the Internet
class Unescaper:
    entity_re = re.compile(r'&(#?[A-Za-z0-9]+?);')

    def replace_entities(self,match):
        try:
            ent = match.group(1)
            if ent[0] == "#":
                if ent[1] == 'x' or ent[1] == 'X':
                    return unichr(int(ent[2:], 16))
                else:
                    return unichr(int(ent[1:], 10))
            return unichr(name2codepoint[ent])
        except:
            return match.group()

    def html_unescape(self,data):
        return self.entity_re.sub(self.replace_entities, data)
```
While I'm complaining, as a Java coder, I'm used to all objects having a "toString" representation, and thus, when logging or debugging, being able to put
```
"this is"+anObject+" and this is "+anOther
```
without worrying about syntax. But Python, otherwise a far superior text-processing lanaguage, won't let you do this: you have to put "str()" or "repr()" around objects you want to include in a string. For no apparent reason. Sigh.
The good news is, the Java SDK now includes a perfectly acceptable HTML parser. I needed to parse attributes in a tag, didn't want to include a whole new JAR in my project for just that purpose, and really didn't want to write that code myself (it'd be like reinventing the wheel in Detroit.) org.xml.sax to the rescue:
```
 class ListingHandler extends DefaultHandler {
  public void startElement(String namespaceUri, String localName, String qualifiedName,
                Attributes attributes) throws SAXException {
      for (int i=0; i<attributes.getLength(); i++) {
       String field = attributes.getLocalName(i);
       String value = attributes.getValue(i);
```
and you don't even have to fuss with XML namespaces if you don't want to (and here, I don't.)
GAEUnit continues to be awesome. Android unit testing continues to be much clumsier. Yet another reason for AppEngine to do most of the tricky work.
Optimization. Always a thorny issue. As a wise programmer once taught me:
The first rule of optimization: don't do it.
The second rule of optimization (For Experts Only): don't do it yet.

The android SDK comes with three excellent documents - Designing for Performance, Designing for Responsiveness, Designing for Seamlessness - that describe best practices. On the one hand, I'm not following them as closely as I could; the ExpandableListView at the heart of my UI is filled with homegrown and relatively expensive ViewEntry objects, rather than arrays as they suggest. On the other, it makes the code a lot easier to read, and ... don't optimize yet. Thus far the app seems fast and responsive enough. Says me. We'll see what others think.

HTTP GETs and POSTs. In case you'd like an example of how to do that fairly efficiently from Android, here ya go:


    public static HttpResponse DoHttpPost(String target, ArrayList params)
     throws IOException
    {
     try {
      HttpPost httpost = new HttpPost(target);
   UrlEncodedFormEntity entity = new UrlEncodedFormEntity
    (params, HTTP.DEFAULT_CONTENT_CHARSET);
   httpost.setEntity(entity);
 
   //configure our request
      HttpParams my_httpParams = new BasicHttpParams();
   HttpConnectionParams.setConnectionTimeout(my_httpParams, CONNECT_TIMEOUT);
   HttpConnectionParams.setSoTimeout(my_httpParams, SOCKET_TIMEOUT);
   HttpClient httpclient = new DefaultHttpClient(my_httpParams);  //get http client with given params
      httpclient.getParams().setParameter("http.useragent", Settings.AppName);
 
   //upload set, let's try it
      Log.i("com.rezendi.wtw.Util", "Preparing to post "+params+" to "+target);
   HttpResponse response = httpclient.execute(httpost);
   Log.i("com.rezendi.wtw.Util", "Sent POST, got " + response.getStatusLine());
 
   //clear out the form data
   entity.consumeContent();
   return response;
     }
     catch (IOException ex)
     {
      Log.e("com.rezendi.wtw.Util", "Error posting "+ params +" to "+target, ex);
      throw (ex);
     }
    }
    
    public static String Encode(String toEncode) throws UnsupportedEncodingException
    {
     return URLEncoder.encode(toEncode, "UTF-8");
    }

    public static String DoHttpGet(String queryUri) throws IOException
    {
        HttpParams my_httpParams = new BasicHttpParams();
  HttpConnectionParams.setConnectionTimeout(my_httpParams, Util.CONNECT_TIMEOUT);
  HttpConnectionParams.setSoTimeout(my_httpParams, Util.SOCKET_TIMEOUT);
  HttpClient httpclient = new DefaultHttpClient(my_httpParams);  //get http client with given params
     HttpGet httpget = new HttpGet(queryUri);

     try {
      Log.i("com.rezendi.wtw.Util","Opening HTTP GET connection to "+queryUri);
      HttpResponse response = httpclient.execute(httpget);
      InputStream is = response.getEntity().getContent();
 
         BufferedReader reader = new BufferedReader(new InputStreamReader(is), BUFFER_SIZE);
         StringBuilder sb = new StringBuilder();
         String line = null;
         while ((line = reader.readLine()) != null) {
          sb.append(line);
         }
         
         is.close();
         response.getEntity().consumeContent();
         String results = sb.toString();
         return results;
     }
        catch (IOException ex) {
      Log.e("com.rezendi.wtw.Util", "Error GETting from "+queryUri, ex);
      throw (ex);
        }
    }

I recommend that you put these in one central Util class, as I did. Mind you, these are static methods on Util, and not (yet) synchronized ... meaning not thread-safe. At the moment I don't think that's an issue; all my HTTP connections are very-low-bandwidth and resolve in seconds, so I can't imagine two such calls realistically colliding unless the phone user has very fast fingers indeed. But famous last words, right? Live by the thread, die by the thread.

In both the Android and AppEngine cases, I started off by writing the tutorials that come with the SDK, and expanded the app from there. In both cases I'm not sure this was such a good idea. I dunno, maybe it's just my OO background, but if I'm writing a Notepad application, I'd like to have an object model with a Note object. But maybe that's not really the Android way. Performance, responsiveness, seamlessness, and all that.
I did like the way they calved all direct DB access off to a DbHelper class, and I've expanded that. Here's a hint; have all your DbHelpers inherit from a common ancestor. Yeah, I know, favour composition over inheritance, but still, here it will save you a lot of time, and give you a central repository for database creation scripts and such. Also, I'm still not exactly sure when you're supposed to close your database objects. In "onPause()"? Immediately after accessing them? Don't bother and let the Activity superclass handle it? It seems unclear.
I'm not sure of the best way to handle error handling in Android. I like to have a common superclass for all my UI objects and inherit error handling from it, but that ain't gonna happen here, as my Activities inherit from various different places on Android's Activity tree. I guess I'll build some sort of ErrorHandler and pass exceptions to it where I think they're most likely to occur? Kind of annoying that there's no single piece of code you can write to catch all exceptions before they hit Android's own error-handling, but I guess that's the price you pay for their heavily compository app system.
Moving back to AppEngine: the memcache service is awesome. Speeds up performance and cuts down on resource consumption immensely. However, for your own good, create a "ClearCache" web handler, for debug purposes. I've twice now spent fifteen minutes wondering why a problem wasn't fixed before realizing that the erroneous data was still in the cache and had not been replaced.
Python's HTMLParser is very useful. However, it seems to have weird problems with ampersands. I think I've now end-run around those problems, in a clumsy kludgy way, but I fear they too may yet crop up again.
This project has included just enough JavaScript (maybe 100 lines) that I wonder if I should have used JQuery, and just little enough that I conclude that I probably shouldn't. Next time, maybe.
I do believe that's all for now. See all y'all in beta, if not before.

GQL blues, or, the bloom is off the rose

2009-06-07T19:37:00.000-07:00

So I've been doing lots of little stuff of late. I wrote my own Preferences edit screen, only to find that Android comes with an automagic one (sigh, although, I also wish this had been more obvious in the documentation.) I explored most of the mysteries of ExpandableListView, which is a pain to use, but would be an even bigger pain not to use.

And I've built the basic spine of my application - an Android app talking to an AppEngine service, which takes a few well-specified requests and feeds back a few tightly structured (and low-bandwidth) responses. The smartphone app never talks to WikiTravel directly; instead it goes through AppEngine, which can a) do all the heavy lifting, b) log and track what's going on, c) cache data more intelligently, d) provide another layer of control and indirection.

It's actually working pretty well; I'm updating WikiTravel successfully. (Well, from the emulator. I'm going to buy a real phone next week, and I expect to unearth more problems with the app when I do...) The UI is sinfully ugly, and right now it can only show you the well-formatted kind of WikiTravel listings to update, and there are a bunch of niggling things to fix and hardcoded strings to move to R.string and kludges to klean up, but by and large I'm pretty pleased with the progress.

However. I have found the first thing about the Android-AppEngine stack about which I have serious reservations. I'm talking about AppEngine's "GQL" data storage.

Now, on the one hand, this object database is quite cool. You can create, save, and write simple SQL-like queries for objects very easily. It reminds me, pardon me while I date myself, of the good old days of working with GemStone for Smalltalk, a wonderfully elegant (but ahead of its time, and hence cripplingly slow) object database for the world's purest OO language.

But if memory serves you could do a lot more with Gemstone than GQL. Especially when it comes to queries. Now, I'm biased from years of experience with SQL databases - I already know how to make them do what I want, whereas with GQL I have to work it out from a fairly thin foundation - but even so, there is much to be desired.

For instance: you can only have one inequality operator (eg "height < 5") in a query. Which means that "height > 3 AND height < 5" is actually impossible to perform. But wait, there's more; if there's an order by clause as well, it must refer to the field that uses the inequality operator. So "height < 5 ORDER BY emailAddress" is similarly impossible. Oh yes, and fetching more than 1000 rows at a time is equally impossible. As is counting all the rows that match a given WHERE clause. The official workaround for that last is to write a Sharded Counter, which, I think you'll agree, is orders of magnitude more complex than writing "SELECT COUNT(*)".

In general, getting around these restrictions means restructuring your object model heavily ... if you can get around them at all. OK, you denormalize databases for performance, and SQL has its quirks and blind spots too, but jeez, this is way past that: it's more like getting a car and being told "Listen, the steering wheel only turns right, so you have to make three right turns every time you want to go left."

I'm sure they have their reasons. Scaling being one. And for an app like mine, where the data-storage requirements are pretty simple and straightforward, this all works fine. But if I was building something seriously data-intensive? I would think not just twice but thrice before using AppEngine, at least until it supports a more fully-featured datastore.

zipme, baby

2009-06-01T21:46:00.000-07:00

So I've finished the first crude version of my middleware and uploaded it to AppEngine. Looks like I'm going to have to upload the indexes by hand, though - I ran it through its paces before uploading it, but got a NeedIndexError: no matching index found when I tried to run it on appspot.com. Oh well. No biggie. I'll do that tomorrow and then go back to my Android app.

But mostly I wanted to tell you about a fun little app called zipme. AppEngine doesn't let you directly examine the source of the files you've uploaded. However, someone named "manatlan" wrote "zipme", a single python file that you add to your root directory so that you can subsequently download the entirety of your source code, zipped, from AppEngine. See here. (It's configured so you have to be logged in as admin, in case you don't wanna show your source to the world...)

eta: spoke too soon - the indexes are now up n' running. However, JavaScript form handling is not. Well, this is why you deploy early and deploy often, so that you don't get bit by it at the last minute. Goin' on a bug hunt, brb...

etaa: in case you're curious, I realized after five minutes that the culprit was neither AppEngine deployment nor my code: it was the NoScript in my browser.

a satisfied customer

2009-05-30T14:36:00.000-07:00

I strongly endorse (at least thus far) the GAEUnit Google AppEngine unit-testing framework, available (for free) here, and insanely easy to use.

Also, don't be a total dummkopf like me and name your initial test file "unittest.py". Insert headdesk sounds here. Fortunately I realized the problem after a mere five minutes of staring at bewildering error messages.

Ajax, king of Salamis, son of Telamon and Periboea. No, wait. That other Ajax.

2009-05-29T12:09:00.000-07:00

So I've been playing around with the web interface to my middleware lately.

(The basic information stream for the app, at least initially, is "Android uploads GPS data, some brief notes, and maybe a picture to the middleware; middleware emails reminder to user to do something with it; user subsequently logs in to web site, conceivably from Android's browser, and uses previously uploaded data to update WikiTravel." I'm gonna add a more direct route that doesn't involve the web site for simple updates, but 'remind me to write this up in more detail later' seems like a more useful function, thanks largely to phone screen sizes.)

Anyway, I stopped writing code just as Ajax - that's Asynchronous Java/XML, more or less, although it has a highly fungible definition - began to take over the web world and begat Web 2.0. So as a mere user, I've always been pretty impressed by it. Saving and loading data within the browser? Cool! Must be tricky!

It ain't. On the contrary, it's really easy. Oh, I can see how you could tangle yourself up in knots with it, but for basic "go send stuff to server / revamp this piece of this page" stuff, Ajax is totally straightforward. Looks like it's often far simpler than doing everything on the server, even.

I did solve one microproblem, so I'll post some code. Ajax is built around an XMLHttpRequest object, which you basically instruct to "go send this request to the server, then get back to me." You then set a callback function XMLHttpRequest uses to get back to you. But I wanted to pass a parameter to my callback function. I wasn't clear on the best way to do this, so I googled, but while there were a few solutions out there, frankly, I think this one I came up with is more elegant. (And I'm sure I'm far, far from the first to work this out.)

Basically, you use the fact that JavaScript treats functions as objects, and write a function to create your callback function on the fly. Sound complicated? It really isn't. Here's JavaScript code to update/expand div with new data from the server:


      var http;

      function getResponseFunction(divName) {
        return function() {
          if (http.readyState==4) { //4 means "done!"
            var element = document.getElementById(divName);
            element.innerHTML = http.responseText;
            element.style.display='block';
          }
        }
      }

      function fillDiv(divName) {
        var element = document.getElementById(divName);
        http = new XMLHttpRequest();
        http.onreadystatechange=getResponseFunction(divName); // customized callback function
        var targetUrl="/expandDiv?divName="+divName; // a call to this URL will return the HTML with which we'll fill the div
        http.open ("GET", targetUrl, true);
        http.send(null);
      }

Voila. Piece o' cake.

(Yes, this project has now expanded to include Java, Python, and JavaScript/DHTML/Ajax code. Hey, it keeps me from getting bored.)

On cloud computing nine. Well, maybe three.

2009-05-27T21:39:00.000-07:00

I've finished the bare-bones functionality of the Android app I'm working on, and have gone back to the AppEngine middleware. The purpose of the app, in case you're curious, is to make it easy to update WikiTravel from your phone, complete with location data and/or a picture.

AppEngine is remarkably easy to work with. And as my friend Martin pointed out, it's now available in both Java and Python (although the Java is still in "Early Look" status.) I'm working in Python for the sake of variety, and also because the advantages of Java in this context are not immediately obvious.

Anyway, I don't have as much Python experience as Java, but that hardly matters, because it's all very straightforward. I'm having a permissions problem getting the location of an IFrame, which means I may have to make things a little more annoying for the user than I'd like, but that's an XSS browser-security issue not a development issue.

The basics of a web application - getting data from the database and request, displaying it to the page, and saving it as and when needed - are all perfectly straightforward; so much so that I'm not even going to bother posting any code here, for once, because none of it seems particularly interesting. Which is a good thing. It means can focus on what you want to do, unlike the bad old days, where you spent a hefty fraction of your time worrying about how you're going to do it.

(I'm sure I'll hit such a wall at some point, and fear not, when I do I will whine about it at logorrheic length.)

AppEngine also gives you lots of freebies. Sending emails easily, for once. Scalability and data integrity, for two. Goodbye, J2EE deployment descriptors; that heavy lifting now happens pretty much behind the scenes, although you do have to group objects affected by single database transactions together in advance.

You also get automatic seamless user handling, so long as you use Google Accounts as your userbase. Caveat; it's easy to link to a login page, but I haven't quite worked out how to integrate a login form into your own pages. Even so, this is pretty brilliant. It means your site comes with all the user headaches - login, logout, password reminder, sending them emails, etc. - pre-handled, saving you time and grief. It also means that if you use it, which I am for the sake of convenience, you lock yourself even further into Google's infrastructure, and expand the tentacular remit of Google Accounts. Good thing they're not evil, eh?