Skip to Content

An SAP employee recently asked in a forum:  “what is the value of SUP for development? How does the Object API save total development effort?”   The Object API is only one of three ways to develop with SUP.  There is also the HTML5/JavaScript Container SDK, and the OData SDK (coming in SUP 2.1), and all three SDKs will be available to developers as the Sybase Mobile SDK.  But this is a great opportunity to show how developer productivity is the core value of the ‘managed object’ approach in the Object API for extending SAP applications (and other data) to mobile devices.

As I was finishing penning the response, I started thinking about Steve Jobs’ comments in the WWDC 1997 closing keynote about developer productivity (41:24 mark in clip):

“The way you get programmer productivity is by eliminating lines of code that you have to write.  The line of code that’s the fastest to write, that doesn’t break, that doesn’t need maintenance, is the line of code that you never have to write, right?  So the goal here is to eliminate 80% of the code that you have to write for your app.  That’s the goal.”

That’s exactly it. SUP’s libraries and code for native apps (the Object API) is a ‘managed object’ approach to developing with on-device persistence, similar to the iOS-specific Core Data framework.  Managed object approaches provide significant benefits to developers by eliminating the amount of code they have to write, and eliminating points of failure.  SUP’s Object API provides the client-side data management functionality, and also provides a huge set of functionality that Core Data does not:

         

  1. The ability to connect to an external data source and authenticate
  2.      

  3. The ability to handle (queue) operations on the database when offline
  4.      

  5. The ability reconcile with the external data source when the device reconnects.  This means processing the format of the result set and writing to the database/exposing to an object ‘under the hood’.  Similarly, it means updating the client database without wiping out pending operations.

These features:  connectivity/authentication, update handling, and queuing are all API features provided by SUP for which a developer could write code, but it would be long, complex, and difficult to maintain.

To understand just how important a managed object API is, I’ve compared the development processes for a purely client-side app that uses raw SQLite, Core Data, and the SUP Object API.  See how the two managed object approaches are quicker to develop and much less likely to be buggy or to break:

Your development process is as follows:

For raw SQLite:

         

  • Write the SQL to create the data structure
  •      

  • Create NSObject classes for each of your objects.  These map to the tables you’ve created in the SQLite db.
  •      

  • Write the query methods for each of your queries that will be needed by the application.  if you’re pretty good, these could be generic (taking the object class types and set of clauses. as parameters), or specific:  -(Customer *)getAllCustomersInRegion:(Region *)region ofGender:(NSString *)gender age:(NSNumber *)age ...
  •      

  • You need to then write the handles for the database results to pass them to the NSObject.  This means if you have 20 attributes (columns) in your table, you’ll be writing a 20-line block of code to accept each item in the result array, assign it a type, and map it to an attribute in the NSObject.  This is a freaking pain, because each attribute is name-specific, and possibly type-specific.  So you can be clever and create a static array of the attribute names for each NSObject, and then iterate through them for this.  But that array is another ordered thing to maintain. The difficulty of maintaining these queries is directly proportional to size and specificity.

For Core Data:

         

  • Use the Core Data modeling tool in xCode to create the data structure
  •      

  • Generate the NSManagedObject classes for each of your objects.  These map to the model.
  •      

  • Use the Core Data framework (including the FetchedResultsController) as your structure for processing SQL statements.  You can use Key Value Coding, which is another thing to learn, but is pretty useful once mastered.  You will still need to construct the SQL statements to input to the FRC.  Fortunately, you can map result sets directly to the managed objects, so that eliminates all the garbage of maintenance described above.

For SUP Object API:

         

  • Use the Eclipse modeling tool to create the data structure
  •      

  • Generate the MBO classes for each of your objects.  these map to the model.  the database is generated at initial runtime ‘under the hood’.
  •      

  • Use the generated methods for returning results from the database.  Results are automatically mapped to managed objects.

So, as you can see:  SUP Object API and Core Data are both ‘managed object’ approaches to persisting and working with data on the device (for iOS). They both require learning to use the API for accessing results, but the benefit in terms of unbreakable code and reducing maintenance is huge.

Where SUP Object API extends that benefit is by also managing the code for connecting to an external data source, authenticating, and updating the databases on both the back-end and on the device.

Really quick, think about the mess of attributes and mapping I described in the ‘raw SQLite’ approach above.

Now, think about the code that you’ll have to write in order to make a connection to your data source, authenticate, submit any create/update/delete operations you’ve stored since the last time you connected to the network (you should also create a flag in your tables to create keep track of that…), then retrieve the current values from the data source.

How will you deal with the results?  Will you write a block of code to check whether each result is an update or not?  Will you just over-write the existing data?  What if the user was working while that happened? What if the results for every user are 5MB, and most don’t have WiFi?

It’s doable. It’s an absolute nightmare to maintain, and SUP provides a huge benefit by handling it all for you.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Paul Garrity
    Stan,
    great article, summarising the development simplicity and security that SUP provides. Wondered what your thoughts were on the linked article
    http://www.gartner.com/it/page.jsp?id=1744514
    It stuck me that with quotes like “at least a third of enterprises without formalized citizen developer governance policies will encounter substantial data, process integrity and security vulnerabilities.” and “IT leaders must be proactive in managing citizen developer initiatives by providing tools that enable transparency in monitoring, change control and analytics.” This supports the value proposition of enterprises using SUP and using managed object libraries rather than native api’s, do you agree?
    Best Regards, Paul.
    (0) 
    1. Stan Stadelman Post author
      @Paul,
      You’ve nailed one of these key issues that’s so interesting about the modern enterprise smartphone development environment:  since two of the highest market share platforms didn’t really exist three years ago, (ok, iOS SDK just over 3 years), so many of those new mobile developers come from outside IT–hobbyists, ‘Type Y’ technology omnivores, these ‘citizen’ developers.   Those are the individuals who have been pushing the boundaries, creating POC’s, exploring the new technologies because this is an exciting moment to see where value can be created.   It’s a time to find out:  where are the new meaningful intersections of data, services, and mobile life?  What are the tool, devices, and platforms in the new space that you want to live with?  btw–SAP has really nurtured this set of conversations, creating a very exciting environment in which to be growing in the mobile space.
      At the same time, picture the scenario in which I go in to our CIO and say, “Mr. Swartz, I’d really like to punch a hole in your firewall so I can test out this iPhone app I prototyped this weekend that integrates conference calling and our PO approval system.  And I really need some live data to work with.”  He has the same obligations to restrict access to information assets in the mobile space as in any other. 
      So I think you’re right to point out the gap here between enabling organizations to leverage the innovation being driven on the edge of citizen development, and the IT policy requirements, and to suggest that SUP can help bridge this.  SUP provides IT a level of trust that the appropriate authentication and security policies are enforced in a mobile app, and enables the developers to focus their cycles on process innovation.  This does fall under the category of using the SUP API/SDK.
      Just as a point of clarity–I think it would be better to re-phrase the value proposition to ‘This supports…rather than writing new code directly in the native api(/sdk).
      –Best Regards, Stan
      (0) 
  2. Patrick Flanders
    Stan, this is one of the most concise descriptions of a specific development issue with SUP. I’m looking forward to more installments in this blog series.
    (0) 

Leave a Reply