Pronoid Android

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