Pronoid Android

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.

Labels: Android, dispatchDraw, MapView, MotionEvent, onDraw, onTouchEvent, onTouchListener, pan, touch, touches, zoom

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.

Labels: Android, building, iPhone, maps, notification, preferences, push, release, resources, Settings

# posted by Jon @ 12:12 PM 1 Comments

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.

Labels: Android, compare, comparison, contrast, developer, environment, IDE, iPhone, Java, language, multithreading, Objective-C, persistence, theads

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.

Labels: Android, background, cursor, database, invalidate, multithreading, SQLite, View, WebView

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...)

Labels: concurrency, concurrent, CoreData, iPhone, multithread, NSManagedObjectContext, NSPersistentStoreCoordinator, NSThread, Objective-C, SDK, threading, UIApplicationDelegate

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.)

Labels: AppEngine, BigTable, chunking, chunks, Images, JPEG, JPG, limit, MemoryError, python, size

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 -

Labels: AppEngine, Apple, AppStore, BigTable, iPhone, iTravel, iTravelFree, python, Wikitravel