New York Tech Journal
Tech news from the Big Apple

#RxAndroid: replace anonymous #callback functions

Posted on November 11th, 2015

New York #Android Developers

11/10/2015 @AmericanExpress, 200 Vesey Street, NY


Trevor John and Alex Matchneer spoke about the advantages of using RxAndroid, an Android adaptation of #RxJava, to simplify the handling of asynchronous events.

Trevor John @PlayDraft introduced the Rx concepts of observables and subscribers. Observables are functions that handle externally triggered events, such as button presses or updates from external devices. The observables can filter and manipulate the results, but are not executed until a subscriber subscribes to it. The structure of observers and subscribers, along with the lambda style of function calls, removes the need for anonymous function calls that were the prior basis for event handling.

Trevor then spoke about the new requirements to create unit tests with RxAndroid. The challenge is to create functions without the extended syntax needed to specify mock events. He talked about some methods to simplify the test code and concluded with general advice on testing

  1. Keep test names short, so you know what it tests e.g.: methodName_context_assertion()
  2. Keep tests short
  3. Limit assertions per test

In the second presentation, Alex Matchneer @FutureProofRetail spoke about lesson learned in extending the functionality of FutureProofRetail’s mobile app. The company has an app which allows customers to purchase grocery items in the store using their mobile app. This allows the customer to skip the checkout line. The initial app has been extended to include item that needs to be weighed. To do this they interfaced a tablet with a scale (using USB), so that customers could weigh items and see a bar code displayed on the tablet. Customers scan the bar code on their mobile phone to include it in their shopping basket.

To streamline the programming logic Alex used Rx.

He created an observable which

  1. Received a character string showing weights from the USB interface with the scale
  2. Filter out strings missing units, decimal points, etc.
  3. Eliminate spurious weights
  4. Wait for the weight to stabilize before displaying the bar code
  5. If the scale is unused, display the “how to use” video on the screen

Alex showed how specific functions in Rx performed these functions

  1. A series of functions specify when a value is received, if the values are repeated, etc.
  2. The filter command removes strings that are not consistent with a regular expression
  3. The buffer command groups individual observations into a overlapping or non-overlapping arrays so the function can easily remove the max and min values and calculate the mean for the remaining values
  4. The switchmap function shows the bar code if the weight is stable for ½ second.
  5. Switchmap can also be used to trigger the video if the scale is currently unused

The observer-subscriber dichotomy simplifies the organization of the code and makes it robust to events triggered by inputs from the scale and user actions.

posted in:  Android, New York Android Developers, Programming    / leave comments:   No comments yet

Android apps: #SQL and #Java, #Designers and #Developers, #Information hierarchies, #Translation

Posted on October 23rd, 2015

New York Android Developers

10/19/2015 @Facebook, 770 Broadway, NY

20151019_190859[1] 20151019_200348[1]

Four speakers talked about different applications and challenges of implementing apps for Android

Kevin Galligan @Touchlab spoke about accessing SQL databases using Java while retaining the best characteristics of object-oriented programming with relational databases.

Kevin talked about the family of Object Relational Mapping (ORM) utilities to perform this linkage. Comparing the offerings is based on performance and structural features. Performance issues revolve around the following questions:

  1. Handling hibernation
  2. Understanding the db structure
  3. Foreign references (parent and child)

However, amongst Android ORMs, there is not much difference on simple tables. For more complicated queries, source-gen is measurably faster than reflection-based. However, Kevin warned the audience not to trust the published benchmark performances.

He then offered a high level comparison of the main ORMs:

  1. ORMLite –lots of apps run this, however is it slow-ish,
  2. Active android – looks like support is dropping off
  3. GreenDAO – external model intrusion, fast (source-gen), single primary key
  4. DBFlow – source-gen, fast, poor foreign relations, support multiple primary keys
  5. Squeaky – APT port of ORMlite, source-gen, single primary key,
  6. Realm – not like SQLite, column oriented, single field primary key, queries tied to thread, fast, foreign calls simple, but it’s under development and is so not entirely stable

The second speaker was Max Ignatyev which is a collaboration tool to improve the communications between designers and developers. It offers a single platform for design changes, thereby eliminating confusion whether communication is via dropbox, email, text, etc.

The designer uses Sketch or Photoshop and the developer sees specs in dp and a common color pallet which is integrated as ready-to-use assets in the IDE. is currently a free offering in beta test.

Next, Liam Spradlin @Touchlab spoke about how users navigate through applications and how to make interfaces so users know what to do next as they complete tasks. He proposed an information hierarchy in which the users see what is to be done immediately in an invert pyramid:

  1. Primary information and actions
  2. Important details
  3. Background information

The last speaker, Mike Castleman @Meetup spoke about the challenges of making more accessible to non-English speakers.

The first challenge is to translate all strings, with sentence translation being especially important to avoid problems with gender and plurals on multiple words in a sentence. They considered third party translators such as Google, but decided to use in-house, native-speakers as translators as they know the product. They also provide context to translators by uploading screen shots. They use PhraseApp as their management tool to organize your translations.

Once translated, the layout needs to be altered as strings often become longer in other languages, such as German.

Dates and times have different forms and punctuations, so they use tools such as CLDR – (common locale data repository) and to get the conventions correct.

Sorting strings and search can also be challenging as some languages, such as Japanese are sorted by the sound of the words, not the actually lexical representation of the spoken words.

posted in:  Android, databases, New York Android Developers    / leave comments:   No comments yet

#Android Development: #Java #Threads, #Video Frame Timing, #Tango, training programmers

Posted on June 19th, 2015

New York Android Developers

Grubhub @ 5 Bryant Park, 15th Floor, NY

Four speakers talked about different aspects of programming/development.

20150618_190536[1] 20150618_190643[1] 20150618_190746[1] 20150618_190841[1] 20150618_191013[1]

In the first presentation, Jamie McDonald @SoundCloud talked about how #RxJava uses a new paradigm in Android for managing asynchronous processing threads.

Android runs all UI processing on the main the main thread, so processes requiring large amounts of resources are better executed on separate threads so as not to impact the user interactions. There are several methods for starting threads and broadcasting the output. These include:

  1. Runnable classes
  2. IntentService for background processes.
  3. AsyncTask which perform tasks by doInBackground with a callback.

Of these, the async task may have the most straightforward syntax, but lack error handing or a good ways to schedule tasks. For instance, a series of ordered tasks must be coordinated in nested async callbacks. Generally, with these methods the execution order of tasks may be hard to control as the operating system has evolved from serial execution to thread pools and back to serial as phones have moved from single to multiple processors.

RxJava (and RxAndroid) adds to this toolkit using a reactive programming framework developed originally by Netflix. It includes a library for observable abstractions with some functional programming. Everything is represented as a stream receiving observables and outputting to subscribers.

  1. An observable receives and operates on objects.
  2. A subscriber states an interest in receiving events and determinates what to do with the outputs or errors
  3. A scheduler links observables and subscribers and specifies which threads handle which tasks.

Jamie, presented code snippets illustrating an observer, a subscriber and a scheduler. He also talked about some of the most commonly used Stream Operators:

  1. Flatmap – takes source and maps to another output
  2. OnErrorResumeNext – recover if something goes wrong

The scheduler can also be used to create a single event bus which puts items in a queue and handles errors and outputs. This can prove especially useful if you change the main screen in which case you merely subscribe to an event on the scheduler’s queue.

But RxJava is new so there are still some issues: unit-test debugging may be challenging for long call chains; there is asteep learning curve with new concepts (e.g. backpressure if the observer is emitting more outputs than can be called by the subscriber). He noted that RxJava still requires code to handle when the orientation of the phone changes from portrait to landscape or vice versa.


In the second talk, Jason Sendros @Facebook talked about the synchronizing the display refresh rate with the animation frame update rate. The standard for screen refresh is 60 frames per second (17 ms), so the software should render its image in less than 17ms.

So, what happens when you miss a frame? Nothing initially. The previous frame is redisplayed and the screen starts its next refresh delay. What happens if you miss a second frame? The display appears jerky or does not scroll smoothly.

How do you detect problems and to fix them? There are several tools/methods to diagnose and fix the problem:

  1. abd shell dumpsys gfxinfo: information on a per frame basis, but cannot be used in production
  2. choreographer: (available after JellyBean OS) gives you the vsync time stamp. So, if you go over 33ms, you can use choreographer to disable the frame output.
  3. Maxframetime is a good diagnostic metric that measures the percent of time spent in buckets: % of time with 0 dropped frames, 1 dropped frames, etc.
  4. Systrace allows you to locate the most expensive worker in each frame. It is superlight so it can run on a user’s device without impacting performance.
  5. Automated testing can be used to look inside high level categories.

He recommended frequent us of microbenchmarks (at Facebook, they will closely monitor the cost of notification for dataset changes) to prevent performance from regressing as the software upgrades are made.

Testing is challenging since one must balance stability of test results (replicability) and performance in the real-world (accuracy).

The meetup was concluded by two lighting talks. In the first, Matthew Davis talked about project Tango which is a stack of sensors supplementing the standard functionality of android devices. Sensors include

  1. A higher resolution camera
  2. motion tracking camera
  3. IR depth sensor
  4. more RAM

The sensors are designed to allow geolocation indoors using motion tracking, area learning, and depth perception to create a visual inertial odometer using key visual markers.

Sensors collect data which is stored in a database, so the system learns about your environment over time. It’s database learns if you have been in the area before and will update the information. Data files can also be transmitted so you can coordinate activities with others (an example is a community cube stacker game in which several players build a common object a la Minecraft).

Qualcomm is designing a hardware set for phones.

Amy Quispe@Coalition4Queens talked about their project, #AccessCode to teach local, disadvantaged students how to code.   Students generally do not have programming backgrounds.

She presented two apps made by students during their 8 week Android course:

  1. 4 function + scientific calculator
  2. Meme-ify – make memes from pictures and background info with text markup that can be shared on social media.

She encouraged audience members to be instructors in the project.

posted in:  Android, applications, New York Android Developers, Programming    / leave comments:   No comments yet