Tips, tricks and techniques to make your native RhoElements Apps faster, more responsive and more efficient.

From our last two developer forums in Bangkok and Birmingham our engineers have delivered an informative presentation on improving your native application performance, concentrating on both code optimization and database access.  Whilst the slides from this presentation are available (https://launchpad.motorolasolutions.com/appforum/apac/1330-1430%20AppForumAPACNativeOptimisation.pdf)  I wanted to walk through some of the tips covered for those unable to attend the forums.

Introduction

Here is a block diagram of a typical native RhoElements application.  A native application is such that it follows the MVC pattern of development, with your business logic stored as models on the device accessing data resident either on or off the device.  This blog will concentrate on those parts of the diagram coloured red and will assume your business logic is coded in Ruby.

Code Optimization

Any application developed for mobile devices must take the hardware constraints into account, this is true of any development framework and every mobile device.  Some of the key constraints are:

• Device battery life
• Available Memory

Power Consumption

The power consumption of your application will be affected by a number of factors but one of the most easily avoidable drains is polling. When writing your application you avoid polling for values from hardware where possible, instead you should register for callbacks to be notified when values change.  The RhoElements API is written almost exclusively to not require polling.

We can take callbacks a step further when we require the status of a server.  Polling a server to determine if our local copy of the database is up to date can be a very expensive, in terms of both Network load and battery life.  Network push notifications are an ideal work around to server polling and there are lots of platform specific push systems out there like iOS push or Google cloud messaging.  From RhoElements 2.2 onwards we ship with RhoConnect push, a new cross platform technology allowing you to do push without the need for a complex, managed solution involving Google or Apple.  You can check out the Webinar on the new RhoConnect push technology at https://developer.motorolasolutions.com/docs/DOC-1721

To further reduce your application's power consumption it can de-register callbacks and stop any other processing when it is sent into the background, this is acheived through the on_active_app and on_deactiveate_app overrides:

class AppApplication  Rho::RhoApplication
  def on_activate_app
    # restore all callbacks and js timers
  end
  def on_deactivate_app
    # remove all unnecessary callbacks and js timers
  end
end

For more information on the activate and deactivate callbacks see the documentation at http://docs.rhomobile.com/rhodes/application#appapplication-class

Memory

The following tips will ensure your application doesn't use excessive memory unnecessarily:

• Don't use big global or class variables, all global and class variables will remain in memory until you nil them.  If you wish to maintain large persistent objects then they should be kept in a database and accessed through the database API, http://docs.rhomobile.com/rhodesapi/database-api/

• Only load Ruby classes on demand as once loaded they remain in memory forever.  This will also decrease your application startup time.

def controller_action
require 'some_library'
#business logic
end

• To improve application performance and stability the Ruby Garbage collector is disabled before each controller action and re-enabled after the controller action exits.  If you allocate / deallocate a lot of ruby objects in your controller action you should call it as follows:

• def my_objects_generator
  • GC.enable
  • #Do some heavy operations
  • end

Performance Metrics

In order to analyse your application performance RhoElements offers metrics to detect inefficiencies and identify where you could speed up your code.

Logging

When written to the log file, logs will contain time information.  Using this time information you can get a quick and dirty idea of where your application performance is slow.

You can enable logging in your configuration file as follows:

MinSeverity = 1 #0 – trace, 1 – info, 3 - errors only
LogCategories = * # category1, category2
MaxLogFileSize=50000 # in kilobytes
LogMemPeriod=5000 #milliseconds

And in your application you can log with the following calls:

puts “Hello!” # will log with APP category
RhoLog.error("Some Category", "Some error message") 
RhoLog.info("Some Category", "Some info message")

Profiler

To better control and quantify your application's performance it is recommended to use the RhoProfiler, http://docs.rhomobile.com/rhodesapi/rhoprofiler-api

Say you had two functions whose performance you wanted to measure, you would use the RhoProfiler as follows:

RhoProfiler.create_counter('Counter1') RhoProfiler.start_counter('Counter1') 
function1() 
RhoProfiler.stop_counter('Counter1') 
#do something 
RhoProfiler.start_counter('Counter1') 
function2() 
RhoProfiler.stop_counter('Counter1') RhoProfiler.destroy_counter('Counter1')
# destroy_counter will log summary of function1 and function2 execution time

And that will write the resulting log as follows:

I 09/18/2012 23:27:20:311 00002ffc PROFILER| Counter1 (0:03:104) : STOP

Data Optimization

There are multiple ways of storing and manipulating data with RhoElements

• PropertyBag (generated by default)
• Data Schema
• RhoConnect (to connect with data at the back end)

Data storage techniques are discussed in more detail at the documentation page for rhom, http://docs.rhomobile.com/rhodes/rhom.  Rhom is a mini database object mapper for RhoElements, providing high level interfaces to use a local database.

You may choose to use a PropertyBag or Fixed Schema for data storage

Property Bag

Simple to use, it doesn't require specifying attributes in the model definition file.

Data migrations are not necessary

Attributes can be added ore removed without modifying the database schema

For some applications, the database size may be significantly larger than for fixed schema.  This is because each attribute is indexed for fast lookup.

Fixed Schema

Smaller database size, indexes can be specified only on specific attributes.

You may use direct SQL queries if and when required.

Schema changes must be handled with data migrations

Database performance may be slower unless you specify proper indices

Tips

Pre-populating the database

If your application requires seeding of initial data then you can use RhoUtils.load_offline_data.

For example, in the rhodes/spec/framework_spec, we use load_offline_data to seed the device database for each test: 

Rho::RhoUtils.load_offline_data(
  ['client_info','object_values'], 'spec'
)

In this example, there is a ‘spec/fixtures’ directory which contains a client_info.txt and object_values.txt pipe-delimited files. For more information on this please see the online documentation at http://docs.rhomobile.com/rhodes/rhom#seeding-the-database. 

You might also consider creating the local database file beforehand, then including the .db file in your application at deployment.  You can use the emulator to achieve this and there is documentation online at http://docs.rhomobile.com/faq#how-to-pre-populate-client-database

Pagination

Often you'll be dealing with long lists of data that the user has to scroll through.  It is very inefficient (and slow) to try and load this entire list all at once, the recommended solution is to use pagination to display say 20 records at a time.  The rhom API offers a syntax identical to rails' syntax and is documented at http://docs.rhomobile.com/rhodes/rhom#rhom-paginate-example

Account.paginate(:page => 0) 
  #=> returns first 10 records
Account.paginate(:page => 1, :per_page => 20) 
  #=> returns records 21-40
Account.paginate(
  :page => 5, 
  :conditions => {'industry' => 'Technology'}, 
  :order => 'name'
) #=> you can have :conditions and :order as well

Tips for using the Property Bag model

Do not use SQL conditions in Model.find, use Advanced queries instead (http://docs.rhomobile.com/rhodes/rhom#advanced-queries):

#Let’s say we have the following SQL fragment condition:
Product.find( :all, :conditions => [ "LOWER(description) like ? or LOWER(title) like ?", query, query ], 
:select => ['title','description'] ) 
#Using advanced :conditions, this becomes:
Product.find( :all, :conditions => { 
  { :func => 'LOWER', :name => 'description', :op => 'LIKE' } => query, 
  { :func => 'LOWER', :name => 'title', :op => 'LIKE' } => query }, 
  :op => 'OR', 
  :select => ['title','description'] ) 

To modify an object in the database, prepare the data first and call update_attributes once.  Do not use save

props = {"name" => "ABC Inc.", “brand" => “Comp2"}
@product.update_attributes( props )

To insert or update multiple objects or models use a database transaction

db = ::Rho::RHO.get_src_db('Model') 
GC.enable()
db.start_transaction() 
begin 
  items.each do |item| 
    # create hash of attribute/value pairs 
    data = { :field1  => item['value1'], :field2 => item['value2'] } 
    # Creates a new Model object and saves it    
    new_item = Model.create(data) 
  end 
    db.commit() 
rescue 
    db.rollback() 
end

RhoConnect

For more information on RhoConnect then please see the user documentation at http://docs.rhomobile.com/rhoconnect/introduction, it's a large topic which I would not be able to adequately cover in this blog.

If your application solution uses RhoConnect to sync its data with the backend database you might consider using bulk sync, http://docs.rhomobile.com/rhoconnect/bulk-sync

Enabling bulk sync either in your configuration file or at runtime will cause the next synchronization with the back end to first be zipped up before being sent to the device. 

To enable bulk sync in your configuration add:

bulksync_state = 0

To enable bulk sync at runtime call:

Rho::RhoConfig.bulksync_state = '0‘

The following actions are performed for a bulk sync:

• The RhoConnect server prepares the sqlite database, zipps it and sends it to the client, running on your mobile device.
• The RhoConnect client receives the database, unzips it and replaces the database on the device, without the overhead of SQL inserts.